eezstreet

+ trip mines on defending team make it damn near impossible

or use a different lipsyncing algo first ;/

The bloom looks okay in the first picture. Needs less saturation. inb4 Xycaleth fixes rend2 EDIT: Wait, this is worded pretty badly.. You should um...cite your sources...or reword this so it sounds like you didn't make this yourself.

There's a mod for that.

Yup. The same happens with misc_model. You can completely ignore these leaks so far as I know.

I think everyone forgot the biggest co-op SW game...Republic Commando. Some missions in OJP don't work or are unable to be progressed. I think you could get up to like vjun2 before it fails?

Or, "we're very careful due to our extensive background in software development" (read: "we're too chicken to touch the code and everyone else sucks, so yeah")

If what AshuraDX says is correct, then it's likely that you just have too much junk being rendered, or too long of a life. Heres some math for you. Suppose we have an efx file. In it, we have a simple spark effect that shoots out 6-10 sparks, with a life of 1200 for each. since the blade effect gets rendered _almost every frame_, that right there is 6-10 tris. Now suppose our client has 90 FPS. That means you're rendering 540-900 tris at any given point in time. For point of reference, the Galak model has around 1.2k tris. With more than one saber onscreen, it becomes obvious why there's issues.

Teamless player is caused by the same thing as it is in MB2. There's entirely too much data being shoved into configstrings that really doesn't belong there for the sake of siege. (For instance...why do we need to know a players model or force config? Both of those are easily available from the client, given a class index?)

You're probably using way too many tris/polygons. The effect gets repeated for each glow chunk of the saber I believe. Try it out with 1 particle, 200ms life and a simple white shader. Note how many times the effect gets repeated.

Here's an example of something new that I have been working on. UI code in particular is something I've been very fond of working on. Despite the code being extremely messy, it provides a very immediate and noticeable effect most of the time. Plus, a lot of the stuff is really cool to tinker with. In JKG, we had the nasty little issue of sliders. And I friggin hate how JKA handles sliders. So I decided to make .menu files able to customize sliders for listbox objects better. Before: After: And here's a sample of the listbox object that shows the server data: itemDef { name serverlist rect 10 112 620 264 type ITEM_TYPE_LISTBOX style WINDOW_STYLE_FILLED elementwidth 120 elementheight 26 font 5 textscale 0.4 textaligny 6 elementtype LISTBOX_TEXT feeder FEEDER_SERVERS outlinecolor 1 1 1 .25 //Highlight when item is selected. visible 1 columns 5 2 40 258 270 40 104 388 5 64 450 20 100 560 20 47 mouseenter { setitemcolor serverlist bordercolor .79 .64 .22 1 } mouseexit { setitemcolor serverlist bordercolor 0.2 0.3 0.5 0.5 } doubleClick { uiScript checkpassword } // new listbox slider-thingy --eez useNewSlider // use new slider code noSliderButtons // do not use up/down arrow buttons floatingSlider // the background of the slider is // independent of the thumb sliderBackground "gfx/ui/mainsub_sliderbarVert" // background shader foreground "gfx/ui/mainsub_sliderbarVert" // thumb shader sliderThumbW 15 // thumb width sliderThumbH 45 // thumb height sliderBackgroundH 290 // background width (floating only) sliderBackgroundW 15 // background height (floating only) sliderTop 124 // slider top Y (floating only) sliderBottom 360 // slider bottom Y (floating only) } Sorry for mangled formating. I'd like to refactor my code someday for tooltips, so we can do something like this in the itemDef: tooltip { type TOOLTIP_INVENTORY } (for hardcoded tooltips) -or- tooltip { type TOOLTIP_CUSTOM text "Aim down the sights to improve accuracy.\n^7(default: ^3Mouse 2^7)" }

Post here with all of your code-related achievements, no matter how minor they may be. Got a cool little command made that shows some elegant new feature? Show it off! I'm posting this here because I know that there's been a lot of big advances lately, and minor little bits of polish are always fun to work on. Screenshots and/or code shown are required.

@@DT85 Xycaleth realized that the renderer is not quite as powerful as once claimed. It uses FBOs/VBOs in very inefficient ways that makes no notable difference in game performance. So, until I figure out how rendering ought to work (or @@Xycaleth fixes it since he knows more about it than I do), I don't have any motivation to work on this.

fixed

This might be a bit heavily biased, but... Demolitions classes are fairly OP, especially on Hoth and Korriban. I think that the max trip mines should be cut down a little bit, and allow for some classes to restore ammo (probably Heavy I dunno?). Also, you should probably fix AMMO_ALL so it isn't silly looking/acting. Lightsabers aren't really highly used on any of the maps (force abuse is pretty crazy though). But that's my two cents. Also fix the doors/bridge on Hoth. And the detpack-win bug on Korriban. Also there's various temp-spec bugs but I'm not aware of all of them.

REMOVE THAT BUNNYHOPPING SHIT CODE IS BAD

He looks like some kinda cannibal to me.

Or you could just check how weaponModel[1] is used, and set it. Both of your examples do that.

In kejim_post, the first racks that I remember are in a room by the level start. There's also two racks on the second floor of the base entrance (same room has two bacta canisters in it)

Wumbology? The study of Wumbo?

Check out how ps->weaponModel[1] is used.

Nope. Doesn't work. Those keys aren't used.