Maybe...just...Maybe?

[Alcatraz]

is it only me who wants to see Imgur: The most awesome images on the Internet Saber Style?
Ahsoka tano, Starkiller and Some other Jedi within the Universe Wielded this saber style.
you are probably thinking
"this is going to be terrible, how are you suppose to block?"

well if you think about it, you can simply have the block animation like this
Imgur: The most awesome images on the Internet

Starkiller Dark Skin Aswell as the saber
Imgur: The most awesome images on the Internet


It would be cool seeing more and more characters and skins added, would make the game more fun in my opinion.
Starkiller is just one example for those who are a fan of the franchise as me.
Adding HK-47 Would also be awesome as a Bounty Hunter.
And so forth!

 

[Alcatraz]

Im sure no-one uses sert

I could add something about this whole HK-47 situation.
IMHO this model still might be worth to include.

As I said before, "legal issues" argument is invalid.
Now about quality of design: is there anybody who can say that skin is ugly and looking too bad for Movie Battles? Maybe it's just my horrible taste, but I see nothing bad in this model.

But let's pretend it's really slightly worse than average mb2 skin. Why do we should be so anxious about number of polygons model has and ignore anything else, like attraction of an character for players?
I mean, there are already enough models for bounty hunter, 19, it's 4-th place among 14 classes. But if we look at that models, question might be brought: are they really more valuable than HK-47?

After all, who are all these guys? Do people actually want to keep each and every of them?
If some players wants that KOTOR droid so badly, maybe it should be given to the people, despite it has 3 polygons less than some brown alien?

There is no serious competition between bounty hunter characters, unlike jedi, sith and heroes, which have a great number of prototypes in SW universe.
If one is to understand what models are best for mb2, one must study all its aspects, not just the dogmatic, narrow view of somebody who judging skins *only* by their graphical supremacy.

Sometimes is better to add a feature that is implemented by only to 6/10 but wanted by customers by 9/10, than keeping the one that is implemented by 10/10 and favorite 4/10.

It shouldn't be series, spamming forum with duplicate threads may be punished.

Personally i would remove the Last model on your Picture.
The 3rd to Last. and 6Th Last. followed up with 10th Last.
I can see people playing other models. i see a lot of fat Greedo and the droid.

 

[Alcatraz]

I believe everyone would prefer much iconic Characters.
Like HK-47
My favorite droid from Star wars, and im not the only one.
KOTOR 1 KOTOR 2 And SWTOR has HK. Even HK- 51 and 55 could be added since they have such great personalities

some other characters too, would be great.

 

[Cat Lady]

Stretching HUD in widescreen

That's actually fixed by some OpenJk commit few months ago (just not implemented in MB2 side, yet)

, and lack of short console commands, at least.

AIUI it is design decision - no more /qui gon jin trolling. Also, tab-autocompletion of commands work, just like it should in any decent console. IMO, the system where closest match to as command is executed (which, by some mistake, may be NOT the command user might want) was just a bad design practice. But, obviously, opinions here may differ

As for CPU consumption, I can't say anything about it - playing MBII on Linux, I obviously have less overhead with OpenJK that with jamp.exe via WINE. Albeit, seeing how OpenJK allows to run Jedi Academy flawlessly on "toasters" (like first Open Pandora - 512 RAM, 900 mhz ARM single core CPU + PowerVR 500 mhz GPU) I don't think it is much of a problem.

In any case, I think that ability to run binary natively on *any* system/architecture, without mumbo-jumbo with full or partial emulation, is tremendous gain, when weighted against (somewhat disputable) cons that you've described. Furthermore, abandoning JAMP.exe compatibility and moving to our own fork would allow coders to stop wrestling with things like already-full client state, arbitrary limits on zillion things, and so on. Trust me (tm), limit of models available for selection at any given time is *smallest* of the issues MBII coders are facing with this old engine, when compatibility with jamp.exe must be ensured "Price"? Open sourcing MBII. For me, it would be additional gain, but opinion may differ, as with everything.
---

That said, I don't think MBII will be going for own engine fork in foreseeable future (or even longer). At the same time, I'm perfectly sure that this *must* happen at some undetermined point in time, if the mod is to be still developed, after certain limits are encountered.

Cheers,
/Cat Lady

// Edit
In the list of gains, there is also hypothetical rend2 (updated, modern graphical renderer) for eye candy. I say "hypothetical", cause - despite working well for experiments:

...is far from being complete, and develops at veeery slow pace (probably even slower than MBII ).

 

[MaceMadunusus]

and switch to our own fork of OpenJK + fix the limitation in engine)

You would have to redo how models and textures are loaded into VRAM entirely (Asynchronous texture streaming <--- multi-threading!!!!!) as well as texture/draw call limitations (API Upgrades). I really doubt anyone working on OpenJK or MB2 has the time for that. It even took Valve YEARS to add that same technology into their own Source engine for major games like Dota 2 that had people complaining about the same engine limitations for a long time.

 

[ent]

Stretching HUD in widescreen

That's actually fixed by some OpenJk commit few months ago (just not implemented in MB2 side, yet)

Text only, and because some of jamme users wanted it in ja++ mod and Raz0r finally decided to work on it.

Implement ratio fix for rotating images too (I offered the devs my jamme commits like 3 years ago lol - none took them) and ojk can finally be competative engine.
MBII uses a lot of rotating images like HP cells in HUD etc.

 

[ent]

That's actually fixed by some OpenJk commit few months ago (just not implemented in MB2 side, yet)

AIUI it is design decision - no more /qui gon jin trolling. Also, tab-autocompletion of commands work, just like it should in any decent console. IMO, the system where closest match to as command is executed (which, by some mistake, may be NOT the command user might want) was just a bad design practice. But, obviously, opinions here may differ.

It mays be good for some users and bad for others. To each their own.

But the main issue is the change is not optional, so you cannot just simply toggle the new and old behavior.
That is the main bad problem of most of ojk changes - no options.

P.S.: that's how true cats (including me) close the game:

https://youtu.be/_UTvv6jxoLc?t=3m32s

 

[Cat Lady]

You would have to redo how models and textures are loaded into VRAM entirely (Asynchronous texture streaming <--- multi-threading!!!!!) as well as texture/draw call limitations (API Upgrades). I really doubt anyone working on OpenJK or MB2 has the time for that. It even took Valve YEARS to add that same technology into their own Source engine for major games like Dota 2 that had people complaining about the same engine limitations for a long time.

But, you're talking about rend2, not just abandoning jamp.exe compatibility, right? Or I am getting it all wrong?

(I offered the devs my jamme commits like 3 years ago lol - none took them)

Shame on them - but that's why I said "our engine fork of OpenJK", not OpenJk per se. Heck, it doesn't even need to be OpenJK, could be JAMME as well, or whatever - I'm rather thinking about inevitable drop of compatibility with JAME.exe, and freedom to tickle in-engine changes itself.

But the main issue is the change is not optional, so you cannot just simply toggle the new and old behavior.
That is the main bad problem of most of ojk changes - no options.

I actually fully agree with that.

/Cat Lady

 

[MaceMadunusus]

But, you're talking about rend2, not just abandoning jamp.exe compatibility, right? Or I am getting it all wrong?

Mostly yes, but it will require some work outside the renderer for it to function properly as well. You mentioned the model limits, which can't be bypassed without modifying those things very heavily. So, doing the engine modifications for that isn't really that fiesable especially when there isn't a resident graphics programmer on either the OpenJK team or MB team. There are people who kind of know that they're doing and are able to figure it out but they are far from pros at creating something like that.

 

[Tompa9]

Every month there are threads about adding new models and so on...let this to developers, they know what they can use, what isnt buggy and so on. They are now adding/creating new Force Awakens skins. Donwload replacements instead, because developers are taking care about skins only about once a year

 

[Damn Polak]

Open sourcing MBII

wouldn't that mean massive leak of mb2team members' dickpics?

Spoiler: what jorge said

^ they make us take pics of us nude so if we ever leak code they will leak our nudes.

 

[Cat Lady]

Actually, MB2 source code is more scary than jorge's dick. *much* more scary.

 

[Damn Polak]

Actually, MB2 source code is more scary than jorge's dick. *much* more scary.

i'd very much like to see it
uhm you know, scientific purposes, no leaks and stuff...

edit: i mean the code, not the dick ofc

 

[Ascot Supreme]

Sure, as long as you program whole animation set for this style (that doesn't look like crap).

BTW, in Full authentic, we have certain characters made to look like using this style. they're basically doing staff animation, with half of the staff off.

In that case you could just replicate it this way, since it already works in FA. Porting it over wouldn't be too difficult.

 

[Cat Lady]

The fact that half of staff work in *some* FA map doesn't mean that it have any sense in open...

 

[Ascot Supreme]

The fact that half of staff work in *some* FA map doesn't mean that it have any sense in open...

The saber style is unorthodox to begin with, a reverse grip is generally unheard of and seems to be better for quick attacks than defense. The point is it still existed, and more saber styles add more diversity to the game play instead of the inevitable future of everyone clutching cyan like it's their babies. It'd be basically simple to port over since it works. Minor tweaking to make it look right.

 

[Cat Lady]

The point is that half of enabled staff is not true reverse grip style - it is still staff, plays as staff, works las staff, minus the half of damage zone. "Porting" it over would basically mean we're creating staff minus - a staff with half the hit potential .And, no, you can't use animations for completely unrelated reverse-grip style, cause every animation would still be same as staff move, including points of collision with blade, etc.

The fact that it is in FA is just for flavor only. it is basically weaker staff (balanced by other characteristics of the class being stronger).

/Cat Lady

 

[{Δ} Achilles]

The saber style is unorthodox to begin with, a reverse grip is generally unheard of and seems to be better for quick attacks than defense. The point is it still existed, and more saber styles add more diversity to the game play instead of the inevitable future of everyone clutching cyan like it's their babies. It'd be basically simple to port over since it works. Minor tweaking to make it look right.

All those Medieval knights running around holding their arming swords backwards, because it totally worked.

 

[Lessen]

holding their arming swords backwards

They actually did this, but in a much sillier-looking but more practical way. That becomes completely impractical with lightsabers, nonetheless.

 

[Ascot Supreme]

All those Medieval knights running around holding their arming swords backwards, because it totally worked.

This is star wars.
Starkiller did it, Ahsoka did it.
Its canon.
GG

 

[Cat Lady]

It actually exist in some forms of far-east swordfighting techniques, and is well-known for western world short blades.

Still, it doesn't change fact that we don't have:

a) decent animations for it
b) sane specifications proposal
c) implementation at any stage of usefulness for Open

...which makes the point exactly as moot as it was at the start of this discussion.