mrwonko

The argument is that without some form of updater/version check people will never update, so that's kind of important to have asap.

That looks useful, though it's only a plugin, and I'd probably need to update my plugin to take advantage of this.

Plenty, I imagine, though I can't remember what I used 10 years ago and it wouldn't be quite the same anyway. Maybe start with the Blender manual?

It doesn't need to be a separate folder, simply extracting the files into base works as well. But you will have to unpack the .gla file as well as the .glm you're importing, keeping the directory structures intact.

You'll have to re-weight it to the skeleton.

Fair point. For your ordinary Mac user we should really just work - it must be possible to include libraries in an app bundle since everything else works, so let's just do that.

I'm not saying it doesn't work, and after 10 years I'm used to it, but it's not intuitive for beginners.

Homebrew is pretty much the go-to package manager on Mac, yes.

Off the top of my head, a mix of both common criticism and my own experience: The whole UI has a steep learning curve; being fully customizable has its drawbacks.When in object mode, one undo erases all the changes made in edit mode. From a programmer's point of view I can see why this is, and I occasionally use it to my advantage, but it makes it really easy to lose work.The reference counting resource user system is really weird to non-programmers as well.Right click to selectCan't edit vertex normalsCan't weight emptiesCan't display vertex indices let alone set themMore stuff I'm forgetting

You're wrong. That's what animation.cfg is for: defining how long each animation is.

Because otherwise the problem space is too large to calculate in real time.

Path length is no issue. But the Program Files folder is read-only in recent versions of Windows; I'd guess that's the issue here. I think Microsoft would have you put your files in My Documents or thereabouts; just keep the .../GameData/base structure so the importer can guess the paths correctly.

Manually graphing pathways is the de-facto standard for all NPCs to move by in all games. There's often some degree of automatic graph generation involved, but it pretty much always still has to be hand tweaked for good results. But you're welcome to write something better, of course.

We wouldn't want somebody changing the description to an ASCII dickbutt without prior moderation so yes, it's normal.

I wouldn't call the waypointing terrible; it's just the map creator's responsibility to include a proper waypoint network.

What are you editing the images with? There's probably some sort of clone brush that allows you to copy parts of the image elsewhere, that should do the job.

I guess something inside the starkiller base would be best suited for Jedi Academy's engine; closed spaces, corridors, rooms. Or inside a ship, for the same reason. I guess the one Han Solo was on would be cool, especially if it contains the Falcon. What? I'm pretty sure that limitation only applies to playermodels. Go crazy. Personally I'd rather see an awesome looking but barely running map; then the OpenJK team can use that as a benchmark for performance optimization. Right. So BSP files can actually contain models directly - I believe they're called trisoups? But those only get per-vertex lighting, which is calculated by Q3Map2. That's your ordinary misc_model. As mentioned you can use a shader to essentially turn them into brushes (force meta or something like that?), allowing them to be lightmapped, but it's much easier to simply give the misc_model spawnflags 4 to achieve this. Steer clear of spawnflags 2 (or 4+2=6) obviously, that's asking for trouble with detailed models. And yes, forcemeta'd models lose their normals, but Q3Map2 can do angle-based smoothing, I think it's q3map_shadeangle? Look it up. Don't worry about LOD, JA was never intended to have them, instead avoid open spaces so the whole map doesn't need to be rendered at once. If your map exclusively uses models and clip brushes, you'll need to manually place antiportals or other vis-blocking brushes to get proper portals, don't just put a big caulk cube around it. I suppose this makes the Han-Kylo-walkway a bad choice, but really I think it'd be too large for a duel map anyway if you do it to scale. Probably avoid misc_model_static, they're a pain to work with since the editor doesn't preview them and they'll only be lit by the lightgrid, yielding even worse results than a non-force meta'd misc_model. The only reason to ever want dynamic models is if you need them to animate. Oh, and one nice trick: You can target a misc_model to a func_* to attach it, allowing you to use models for doors, lifts etc.

Well I loaded the autosave of t1_rail and finished it and encountered no problems starting the next level.

I wouldn't be so sure, Ruxith; before you can write to a file, it also needs to be opened. So it may be a rights issue where Blender is not allowed to write to the target folder. Are there any errors on the console?

Well, since portals work by first drawing the scene they're linked to and then the original scene on top of it, there's really no way to have multiple at once without engine changes.

I find the "Mac" part more interesting than the "old". Maybe it only works on Mac?

I even started the mission and played half of it, no issues...

I think he misspelled Postal. I didn't know that had portals though...

Looks fine to me on fs_game openjk/Windows with latest build (built locally); I started a new game and played a bit until I could select my first level, chose t1_rail and it works just fine.

That's a weirdly specific issue... We should see about getting that fixed.