I made two posts in the Jedi Knight Edditing/ Coding forum but i didnt get any help or even replys on it. so keshire told me to post it here, i hope i get here at least a reply on it. this is a coding thing so it fits quite good into OJP. i put both into this thread cause they are some kind of dependent.
fix vehicle limit
Now with the JA sdk released we can do some more in deep changes of JA. as i am working on some new vehicles i would like to start this thread on how we can mod JA to eliminate or at least rise the vehicle limit.
the vehicle limit has something to do with the .veh files. if there are more the 12 added in the base folder JA gives you an error back when loading a map: veh files extention to large, or something like that. its eighter a limit of the number of veh files or the used size of all these veh files together. i couldnt figure that out.
to fix that is very importent for us vehicle modelers, everyone downloading vehicles surly gets the problem of the many veh files. and for mapper its a limit of the vehicles they can use in thier maps. i dont realy have an idea about coding, but with my other request for help in creating new vehicle classes, i hope this can improve our projects a great part. if someone could help me figure out where the problem is and fix it, would be realy great.
creating new vehicle classes
I am working on some new vehicles for JA, like the droideka, and came to the point where without code change i dont realy can finish it as i would like to. the problem is the vehicles in JA are grouped in classes like swoop, walker, fighter or animal. these groups are more importent for how the vehicle is like then the .veh file, which we can mod. creating new vehicle classes would make it possible to creat new vehicle models which are more acurate. for ex. to creat a ATAT usabe we need a vehicle class that can move a head independently from the body or sett up directly what triggers a spezified animation. just to make it clear, i have no idea about coding or any other stuff needed for that. so i am writing here a list of what i hope could be changed or set up in a new vehicle class. perhaps we should creat some different classes so there is some choise for us vehicle modelers to creat new vehicles. if you could help me, would be great
-more variety in movements, some classes have more different movements, but any vehicle can drive sideward or jump. for ex. it could be possible to creat an animal that can make a high jump.
-let bones follow the crosshair, the ATST guns does follow the crosshair in the vertical, a bone named >thoracic< in a walker class vehicle does it. if we could set up bones that follow in horizontal and vertical. or also let the vehicle turn when standing, what work in SP but not in MP.
-using left/right arrow to steer and mouse to aim, this is directly linked to the point above. instad steering the vehicle with the mouse it should work though the arrows. thise would make vehicles like ATAT or ATST much more accurat.
-finish an animation sequence befor a next one can be ativated, the vehicle class seams to set up which animations can be inerrupted and which cant. for ex. my droideka goes much to fast into rolling mode and back, i want to have the sanding up animation finished befor any thing else can be started.
-deactivat sertain actions in stances, for ex. the fighter class cant shoot while standing on gound, i would like to have a similar thing for other actions during some animation sequences. again my droideka, i want to have it set up so it cant shoot while in rolling mode.
-taking different amount of damage in different stances, for vehilces it should be possible to set up a very vulnerable mode, or have some kind of activated energy shield in some animation sequences. i am not talking about the visual part of it, i already created such a visual energy shield for my droideka, that is activ while standing and not when in rolling mode. i would like to have a mod that takes that into account on the damage points.
-more different driver posture, this is set up in the vehicle class altough the is a parameter in the veh files, but it has no effect. if we could set up that other posture are shown and what player model animation sequences are used. for ex. useing that console typing animation for a vehicle driver.
-vehicles with passangers and possibly show them as drivers, there is an option in the veh files to make it possible for vehicles to carry passangers, but its a vehilce class thing again. if we could make it usable and those passangers visible with spezified driver animations. gunner is perhaps the next step, but i suppose thats hard coded.
ok, thats my short list. i am not sure if i mentioned all, but these are the things i realy like to have on my vehicles. i have no idea if its possible at all, so let me know.
I'll look into the vehicle limit but I simply have too much on my plate to create new vehicle classes. Maybe someone else would like to do that.
Ok, it looks like the max vehicle issue is just a single DEFINE. I've made the change and will update the repository soon.
sounds great. everyone knows you got lots of things on your to do list, so it doesnt hurry. i am happy at least someone replyed to my post :)
I've got VH_DROIDEKA defined for you Duncan.
At the moment It is exactly like the ATST.
I'll be changing that shortly.
Is keshire going to share some with the rest of the class? :)
Soon as I'm done.
I'm hunting down where the attack string is so I can insert an animation there. Something general like BOTH_ATTACK2.
Also need to hunt down the movement area for run. Which shouldn't be too hard, I came across it once before. Just need to re-find it. ;)
Well, if you're planning on submitting anything to the project, I suggest you get access to the repository so you can do the adding yourself.
Could you perhaps point me in the right direction for that?
I'm probably going to have to walk you thru it. PM me your IM information.
Well I'm primarily on while at work. Get ahold of me at
snip
As you can see I monitor my emails as if it were IM. :)
Duncan_10158,
I am going to be starting work on implementing a Droideka class for my mod soon - and was planning to sumbit this to the OJP. The only trouble is I wasn't planning on using a vechicle implementation for the Droideka because - well - it's not something a player rides!
...wouldn't it make more sense as a siege class?
...however, I might still be interested in working on these new vechicle classes as well - irrespective to the droideka implementation.
Anyway, if you want to get in contact so that we can xchange notes more closely, my e-mail is renegadeofphunk@3dactionplanet.com
I emailed you the Droideka file and explained to him what you wanted to do. I decided to do this (vehicle class) as a side project.
I'll try and fix the attack while running and adding in the attack animation tonight. Otherwise I'm out for the day.
Originally posted by RenegadeOfPhunk
I am going to be starting work on implementing a Droideka class for my mod soon - and was planning to sumbit this to the OJP. The only trouble is I wasn't planning on using a vechicle implementation for the Droideka because - well - it's not something a player rides!
That's true but it might be easier to impliment as a seperate vehicle class that is only boardable thru code commands.
That's true but it might be easier to impliment as a seperate vehicle class that is only boardable thru code commands.
Hmm - I think you have a point...
I would want the droideka 'class' to be avaliable irrespective of whether the droideka vechicle happens to be included in the map, but I guess I can jump that hurdle later...
OK - so I'm definetly interested in helping with all the stuff your talking about Duncan. I wasn't home last night, so I didn't check my mails. I will check them tonight.
Keshire, maybe we can split the work between us. Let me know where you are currently at...
Have at it. I just have a copy of the walker class renamed. I'm tackling my other project at the moment.
this is coming great, thanks everyone.
my first idea was to creat the droideka as player model and not as vehicle. most of the animations are made as it would be a player model. i converted it to vehicle as JA came out and the hole vehicle thing got possible for MP. i also think to code the droideka as vehicle and make it in siege maps for ex. boardable only class selection, as razorace suggested, is the best way.
RenegadeOfPhunk, did you get the droideka file? if not let me know and i will sent it again.
btw, could it be possible to change the code that in the veh file are some of these options to enable? for ex. which animation sequences are used or what bones follow the crosshair horizontaly or verticaly. that would make it for everyone much easier to creat new vehicles.
btw, could it be possible to change the code that in the veh file are some of these options to enable? for ex. which animation sequences are used or what bones follow the crosshair horizontaly or verticaly. that would make it for everyone much easier to creat new vehicles.
The animation triggers are most certainly possible. (Sounds like Keshire has made some headway into this already...)
The bones-following-crosshair stuff I'd need to look into a bit, but I'm sure that should be possible too...
Yes, I was in the process of hunting down where the attaack occurs so I could implant just any basic attack animation. The only problem I see is the way it switches linked muzzles.
I don't know if the animation would occur before or during the switch.
During would be definately be nice and make less work. But I'm just hoping.
Duncan,
I haven't recieved your current Driodeka work yet. I'm assuming your planning to send me your current vechicle implementation so I can see clearly what needs to be altered / fixed.
...also, have you got an AT-AT in the works? If so, it would be handy to be able to see that too, so I can get a clear idea of what needs to be achieved for that too.
One thing I think I will do is add a variable to the standard vechicle definition which states that the vechicle is something that the player 'is', rather than the player 'rides'. Exactly how we want to make this work, we can think about as we go.
I can try and add a lot of customosability to all the vechicle classes, to try and achieve the things your after, but I need to know some details.
e.g. with the droideka, how is it you are switching from roll to not rolling?
Anyway, if you send me a mail then we can get communicating properly...
Keshire,
I don't know how your approcahing this, but it would be nice if we make this work nice and generically, so that - for example - a vechicle creator could make another 'droid' vechicle, and specify special operational modes, special anims etc. all from the vechicle definition without having to change any code. I think this will be a bit tricky, and we can't try and cover EVERY possibility - but I think we can try and make it fairly comprehensive...
Keshire,
Just looked back up, and seen that you have created a new class specifically for the Droideka.
...I reakon it would be better to leave it as just a VH_WALKER class. That's essentially what it is after all, with a few extra fancy functions.
We can get those new functions in by just making ALL vechicle classes a bit more customisable, but I personally don't think adding new vechicle classes for individual instances of a vechicle (i.e. Droideka) is the right way to go - not in the long term anyway...
..what do you think?
OK,
While I'm waiting to look at the current Droideka vechicle imp. - here's an example of the kind of things I want to add to the .veh definition files to try and handle the stuff being talked about.
e.g.
To handle the jumping stuff...
MaxJumpHeight
Default - 0
Determines the maximum height this vechicle can jump to. If 0, this means the vechicle has no jump capability. I'm guessing only VH_WALKER or VH_ANIMAL vechicles would potentially have this variable set, although I guess VH_SPEEDER isn't out of the question either...
JumpVelocity
Default - ?
The velocity with which the vechicle will leave the ground when jumping.
JumpAnim
Default - ?
A custom anim to be played when jumping.
From the looks of it, you guys have already got new anims working for vechicles. Could I get details as to how that all works...?
I assume this stuff will be submitted to OJP?
Well, if you're actively working on something for OJP, please post about it in the "what's new?" sticky.
please post about it in the "what's new?" sticky.
Done.
btw Razor - this max vechicle DEFINE you've upped -do you know why it was set so low? I'm guessing Raven didn't set it low just to spite us! Maybe they had a good reason for it...
...anyway, I've got jumping vechicles now :)
Gotta iron out a few kinks and add those new vechicle options, but pretty much done.
The only thing I can't get working yet is getting a jump anim to trigger. But I think this is mainly because the AT-ST I'm using to test with doesn't have a jump anim defined ;)
Duncan, if you have a vechicle which DOES have a jump anim ready to be triggered, then pass it my way and I can try and get it working properly...
Well, 16 seperate vehicles isn't that low...especially if you consider that they got cut off in midstream on the vehicle stuff.
In fact, the define states that it's 64. They must have reduced it right before release. My guess is that it's so that the loadtimes are smaller.
Hmm. Well, ok, we'll see how it goes I guess.
Anyway, I've coded in the new entries to the vehicle definition I mentioned above. i.e.:
MaxJumpHeight
JumpVelocity
JumpAnim
They seem to be working fine.
There is only one small problem I have, which seems very strange. If I make the vechicle jump 'on-the-spot' in certain parts of the map, the vechicle can tend to 'drift' a bit until it settles on a certain, specific point!!
...I'm still looking into it, but if I can't get it fixed, it's not a show-stopper I dont' think.
As I say, I can't test the jump anim stuff properly until I get a vechicle with a jump anim defined.
OK- since I still don't have a current Droideka file, nor do I have any details on how your currently handling stuff like rolling, I'm going to propose my own system for handling this kind of stuff.
What I'd propose is to mark out several differnt operational 'modes', activated in different ways.
...for example, the way I was planning to handle Droideka 'rolling' was to make rolling active when the 'crouch' key is held down
OK - so what I propose is to have the concept of different operational 'modes', triggered by custom-defined player input.
i.e.
OPMode1
Default - MODE_TRIGGER_NONE
Determines what control triggers this 'mode'.
Two triggers I can think of off-the-bat are:
MODE_TRIGGER_CROUCH - mode triggered when crouch is held
MODE_TRIGGER_WALK - mode triggered when walk is held
I guess these different triggers could be bit flags potentialy, although I don't know how useful this will be.
Mode1AnimStart
Default - ?
Determines the anim which is played when moving into the specified operational mode
Mode1AnimDuring
Default - ?
THe anim which is played 'during' the operational mode
Mode1AnimEnd
Default - ?
The anim which is played when coming out of that operational mode
Mode1CanFire
Default - 1
If set to 1, this means the vehicle can fire when in mode 1. If 0, it cannot
Mode1ShieldsOn
Default - 1
If set to 1, this means shields can still work when in mode 1. If 0, they cannot.
Mode1VehicleClass
Default - ?
This entry determines new class values to be used to 'over-ride' the normal ones. This allows maximum flexibility between the different operational modes.
For an example of how this would work, imagine a Droideka_vehicle class. THe values speficied directly for that class would be for walking.
The Mode1 settings would look something like this:
OPMode1 MODE_TRIGGER_CROUCH
Mode1AnimStart ANIM_DROIDEKA_FOLD_UP
Mode1AnimDuring ANIM_DROIDEKA_ROLL
Mode1AnimEnd ANIM_DROIDEKA_FOLD_OUT
Mode1CanFire 0
Mode1ShieldsOn 0
Mode1VehicleClass "DroidekaRolling_vehicle"
The DroidekaRolling_vehicle class could contain any settings which would need to be 'over-ridden' when in this mode. Some examples of this would be overall speed, turning ability etc. etc.
Also, one extra setting for all vehicle class would be:
VehicleModeClass
Default - 0
If set to 1, the class definition is only a mode of another class, and cannot be used as a class 'on it's own'.
If 0, this is a 'normal' or 'main' class.
i just sent the droideka off, RenegadeOfPhunk. it has jumping animations so you can experiment on it. the modes you are talking about is quite the same i was thinking about. to activat rolling mode through holding shift or toggle by caps lock is as i made it in my JO version of the droideka. but the mode changing animations, fold_up/fold_out, should be shown completly befor another action can be taken.
this is great, thanks everyone. we can make a great addion to JA!
Thx for sending me the Droideka file Duncan.
Unfortunately, I can't check it out because just after I had turned my PC on, a large bang came out of it and then it powered down.
...the f**king power supply has gone and blown!!
...or at least I hope that's all that's happenned... :/
I'm gonna get it looked at tomorrow, so hopefully I should be back up and running as quickly as possible.
but the mode changing animations, fold_up/fold_out, should be shown completly befor another action can be taken.
Agreed. I think this should be a standard feature for all vehicles which have these different 'modes'...
Yes the way I was going about it is not ideal. But then again I'm not really a coder. and its learn as I go.
Yes the way I was going about it is not ideal. But then again I'm not really a coder. and its learn as I go.
...you seem to be doing pretty well :)
Don't take what I was saying the wrong way. I was just making sure we agreed on how we should approach the problem.
...OK - now all I need is a computer that doesn't blow up when I switch it on - and I can get cracking ;)
...should be fixed tomorrow...
Don't take what I was saying the wrong way.
Wouldn't dream of it. I was just stating a matter of fact. Soon as I get my throwing code done, and Monsoontide's Acklay smoothed out animation wise. I'll do what I can to help out.
Now that my computer is now (finally) up and running again, I have managed to make good progress on the Droideka-specific vehicle implementation.
I know have:
* The fold in and out anims working correctly (i.e. no movement or firing happens during them).
* Custom sounds triggered during these fold in / out anims.
* Firing disabled when rolling.
All the above stuff is generic (all configurable from the vehicle definition file), and so this kind of stuff can potentially be applied to ANY vehicle quite easiely.
THe only thing I have left to get working are shields. That shouldn't take too long though.
...I'll probably get it all added to the repository as a Christmas present :)
I really suggest that you use animevents for the fold in/out sounds. It's MUCH easier to set up and it frees up some brandwidthby doing it on everyone's client side.
Also if you haven't already set up the animations to use the standard enums already present for certain actions.
such as BOTH_STAND2toSTAND1 transitions. It should make custom animation.cfg's more streamlined.
I really suggest that you use animevents for the fold in/out sounds. It's MUCH easier to set up and it frees up some brandwidthby doing it on everyone's client side.
...ok, I'll look into that
Also if you haven't already set up the animations to use the standard enums already present for certain actions.
such as BOTH_STAND2toSTAND1 transitions. It should make custom animation.cfg's more streamlined.
I may not be understanding you correctly, but (I think) this is how I am approaching things.
For the Droideka, there have been two transitions I have needed to implement : walk to run, and run to walk.
For walk to run, I've used the BOTH_RUN1START anim
For run to walk, I've used the BOTH_RUN1STOP anim
These are 'hard-coded', and not configurable from the vehicle definition. So these would be triggered for any vehicle (if the transition anims are enabled in the first place mind you - this IS in the .veh definition).
I'll try and expand this list and put in support for as many additional, sensible transition anims that I can. (Including your example of BOTH_STAND2toSTAND1)
WHat IS configurable at the moment is how long movement is disabled during the anim, what 'modes' can fire primary and alt weapons etc.
I'll post up full details once my implementation is a bit more complete...
OK - droideka implementation is pretty much finished.
Attacking can be disabled in the appropiate modes.
Shields can also be disabled in the appropiate modes.
Transitions between walking and running (rolling) are working correctly.
But before I sumbit this stuff to the OJP, I'd like to provide support for all the different mode transitions. So I'd like to get some feedback about which anims I should use for each transition.
So far I have:
Walk -> Run: BOTH_RUN1START
Run -> Walk: BOTH_RUN1STOP
If anybody really wants these to be different, I can change them. But I think those are sensible.
The ones I still need to decide are:
Still -> Walk = ?
Walk -> Still = ?
Still -> Back = ?
Back -> Still = ?
I can't really see any anims which seem to directly associate, so I'll let you guys choose :) Just look in anims.h and choose an enum for each transition I've just listed above.
..the choices don't make any difference to the implementation, but I guess we should try and choose ones which will make sense to most...
Oh, and Razor. YOu reakon this stuff is Basic Or Enhanced?
..I'm thinking it's Basic...
OK - after watching Ep.I, I've realised that the droideka's shields are only on if it's standing still. When they start walking or rolling, they switch off...
...so I've set that in the droideka.veh file (Good job I made this stuff customisable :) )
I've also ripped some sounds from the films and added them to the droideka using the aminevents stuff (very handy indeed - nice work Razor...)
SO I reakon the Droideka is ready to be submitted.
I'll just give people a chance to choose what anims they want for the transitions I mentioned above. If I don't get any by tomorrow, I'll just pick some myself and submit this stuff to the repository...
Here's the details of the extra vechicle definition entries I've coded in:
MBFstopprimaryfiring
MBFstopaltfiring
MBFdisableshields
These three are Mode Bit Fields (MBF) and they use the following bits:
typedef enum
{
VEHICLE_MODE_RUNNING = 1,
VEHICLE_MODE_WALKING = 2,
VEHICLE_MODE_BACKWARDS = 4,
VEHICLE_MODE_STILL = 8,
} vehicleMode_t;
THe names should be self-explanitory
WalkToRunTime (ANIM: BOTH_RUN1START)
RunToWalkTime (ANIM: BOTH_RUN1STOP)
These two ints set the time (in ms) the vehicle will pause and play the corresponding anims. If set to 0, the transition anims won't be played at all.
Whilst in transition, no movement or firing is possible.
Here are the values I currently have set for the Droideka in it's .veh file:
MBFstopprimaryfiring 1
MBFstopaltfiring 1
MBFdisableshields 7
WalkToRunTime 1000
RunToWalkTime 1000
i think thats perfect for droideka! i didnt know that they can have shields only when standing still, but thats perfect. it doesnt make them to strong and they have a fair weekness.
about the transitions, to be honest i have no idea about that so i belief in your desicion. the easier the better :)
i dont know if you mentioned it, but did you take a look on the turning when standing and bone follow crosshair thing. they are not importent features, i just ask if i missed it.
1. Where are these flags stored? I assume they're either in the playerstate on the server.
2. Remember to do make clear documentation of all this additional material. I suggest you use the OJP_Vehicles.txt that already exists. It will have to be cleaned up thou. :)
3. How did you decide on how to become the Droidika? Is it something that players enter or something that you choose to be?
i dont know if you mentioned it, but did you take a look on the turning when standing
Doh - forgot about that!
...but I've taken a quick look now and I've got that working OK. There is actually an option for this in the .veh file - turnWhenStopped. But it doesn't seem to do anything in the base MP game (at least not for Walkers) -so I've made this option do something now :)
and bone follow crosshair thing. they are not importent features, i just ask if i missed it.
I haven't looked at the bone stuff yet, no. I was concentrating on the Droideka stuff at this point. The droideka doesn't really need horizontal bone-turning at this point -it looks ok to just make it 'walk-on-the-spot' when it's turning...
I think I'll get all the stuff to get the Droideka working submitted first. I think it would be good to allow that to work nicely in-game as soon as possible. THen I'll move on and try and add all the other stuff in a later version.
1. Where are these flags stored? I assume they're either in the playerstate on the server.
The new additions are in two structures:
Vehicle_t
vehicleInfo_t
2. Remember to do make clear documentation of all this additional material. I suggest you use the OJP_Vehicles.txt that already exists. It will have to be cleaned up thou.
Sure, will do.
3. How did you decide on how to become the Droidika? Is it something that players enter or something that you choose to be?
I've just made it enterable like any other vehicle at the moment. It would be some work to make the droideka 'selectable' effectively as a new player type. I'll have to look at it at some point for my mod.
But for the OJP, I'd also be concerned about whether the Droideka was really balanced enough against normal players with access to all the different weaponry etc.
...as a proper vehicle, at least you can jump in and out during a game at will...
...maybe this is something we can determine with some playtesting. On this subject, do we have beta testers who will test new OJP builds before we release them?
...if not, should we get some? :)
Well, I have some suggestions on how to balance things:
1. use the shield effect seen in SP. The SP shielding effect prevented saber users from getting close enough to do damage without getting zapped.
2. Make the droidekas walk very slowly to make up for this obvious advantage.
3. Give the Droidekas a fairly low turn rate.
4. make the Droideka shots be double blaster shots like we see in the movies.
As for betatesters, yes, we do have one betatester.
1. use the shield effect seen in SP. The SP shielding effect prevented saber users from getting close enough to do damage without getting zapped.
2. Make the droidekas walk very slowly to make up for this obvious advantage.
3. Give the Droidekas a fairly low turn rate.
4. make the Droideka shots be double blaster shots like we see in the movies.
All these things you mention are in - in some form.
The droideka has shields which are only active when standing still (or turning on the spot - it's possible we may want to deactivate the sheilds even then..)
They also have a relatively slow turn rate already.
And they can fire double-shots now as well.
But anyway, I think I should submit this as just a 'normal' vehicle for now, and let people playtest it a bit. I think the different features you've listed would need some tweaking before they could be considered properly balanced - and hence appropiate as a player-type...
...and the best way to test it would be to just release it as a normal vehicle and let the great unwashed (or at least the OJP beta-tester(s)) take it for a test drive. :)
...besides, the base game isn't exactly steeped in realism - so I dont' really think the 'unrealism' of boarding a Droideka is going to be a massive deal to most people...
Well, I'd have it so the Droidekas can at least walk with their shields up.
..that's not how it is in the films, but yeah, we may have to do that for gameplay balance - at least in the OJP...
k - fair enough. So your current walking-with-shields animations are probably OK Duncan. At least for the moment...
Another thing to consider is that allowing players to spawn directly as a Droideka should really be an Enhanced feature - since that would substantially affect basic gameplay.
The droideka as a normal vehicle could stay in Basic though I reakon - 'cos it just a normal vehicle with a few tweaks...
Originally posted by RenegadeOfPhunk
..that's not how it is in the films, but yeah, we may have to do that for gameplay balance - at least in the OJP...
I thought the first time we saw them in E1 they were able to walk with their shields up.