It
#631 posted by gb on 2014/01/10 20:26:53
requires a custom progs.dat, naturally, like hiprotate does.
#632 posted by metlslime on 2014/01/10 20:51:47
I would point out, i don't think the word "proper" should be used here -- doesn't it just rotate the hulls? (Sure it makes the mapper's life easier but) collision hulls are not equal on all axes -- the player is taller than he is fat, so collision hulls have more height added than they do width. Probably the results are fine as long as you only rotate on the Z axis. But if you tip an object onto its side (like a drawbridge) it will look funny when you try to walk over it.
Metlslime
#633 posted by mfx on 2014/01/10 21:46:27
Been playing around with the Rubicon2 entities and all that rotating stuff. Why is the texture alignment on, say a hatch that only opens 90 degrees, totally screwed?
and setting up those func_movewalls for collision is elaborate(to be honest a pain in the ass..)
Sorry for the wrong thread, just had to let it out:)
Mfx:
#634 posted by metlslime on 2014/01/10 22:20:36
the texture alignment on rotators is a compiler bug, i hope someone fixes that someday.
and yes, func_movewalls are annoying to set up. Though they don't really take that much time, it bothers me more how limited they are in functionality.
Mfx:
#635 posted by metlslime on 2014/01/10 22:21:39
oh, if you are asking about why the texture alignments are messed up in the .map files for rubicon2, that is to correct for the compiler bug. I had to make them look wrong in the editor so they would look right in the game.
Ahh
#636 posted by mfx on 2014/01/10 22:35:02
So this is at offset 0 0 0 i guess?
Confusing..
Mfx:
#637 posted by metlslime on 2014/01/10 23:36:02
yes, my technique is to move the model so to 0 0 0, fix all the texture alignment, then (with texture lock disabled in the editor) move the brushes back to the correct location in the world.
Metlslime:
#638 posted by mfx on 2014/01/10 23:41:08
Center of model at map origin?
Or the lower left corner of the bbox put at origin? (Like when path_cornering?)
Mfx:
#639 posted by metlslime on 2014/01/11 00:20:22
lower left corner (i'm pretty sure)
Metlslime:
#640 posted by mfx on 2014/01/11 00:25:16
Will try out, thanks!
Is there a chance a compiler(like BJPs Tools)
could be fixed, so that this setup is irrelevant?
Just curious.
Nope!
#641 posted by ijed on 2014/01/11 01:35:18
But we're capable of improving what is there, the reason I'm asking.
Props go to Gb for writing the original qc frontend.
Easier for the mapper means we'll see more rotating things in maps, and I can't see how that could be bad (disclaimer).
I'll implement the code from RMQ in RRP for now.
If you don't build it, then it's not built.
Metlslime
#642 posted by gb on 2014/01/11 03:14:14
they're solid_bsp.
#643 posted by necros on 2014/01/11 05:43:14
It causes an intermittent 'pop' when looping sounds wrap around - this has been driving me crazy for years!
omg THANK YOU. I hated that pop!
Ok - Since no-one's reported sound niggles, Eric's sound loop fix is committed.
ijed: [mouse] Is still locked in top left corner if I alt-tab out, from the menu, console or otherwise.
Hmm - i'll have to test it in windows sometime. It works acceptably for me on linux, but if it's broke on OSX/windows it may have to be reverted. My change was just a hack-and-see.
Re other changes - i can't say. I guess if people feel strongly, patches are welcome, but main focus is to fix things, not break them ;>
Mouse / OSX
I can't tab out of the engine, but I can put it into windowed (alt+enter) and then hit ESC to show the menu, which will release the mouse pointer.
-
Well i guess we'll have to remove the hack.
Maybe there's some other SDL befuddlery to get it going...
Another Request!
#647 posted by ijed on 2014/01/13 14:27:30
How about a patch to remove the 4096 +/- limitation?
4096
#648 posted by Kinn on 2014/01/13 17:18:57
Isn't that limit there to stop floating point hilarity with large world coordinates?
#649 posted by Preach on 2014/01/13 18:57:33
Isn't that limit there to stop floating point hilarity with large world coordinates?
Sort of - the hardest limit on coordinates comes from the standard network protocol, where entity coordinates are sent as a 16 bit integer (so fixed precision at 1/8th of a unit). Even with a less bandwidth efficient netcode, server-side locations are recorded in floating point. Before you could make truly huge maps you'd need to consider upping that to doubles for precision of small movements (and then deal with how QC can't handle doubles).
Hm
#650 posted by ijed on 2014/01/13 19:12:44
So it's not just an arbitrary limit then.
Ok, will make stuff fit instead.
If Warp And Ne_ruins Fit
Then everything can fit.
Apart From
#652 posted by ijed on 2014/01/13 20:12:49
My train line :*(
#653 posted by anonymous user on 2014/01/13 20:36:51
if it wasn't for the 4096 limit, i'd probably still be making ne_ruins now... -_-
You Mean You've Stopped?!
#654 posted by ijed on 2014/01/13 20:50:11
RMQ
#655 posted by Drew on 2014/01/21 05:01:08
still horrendously slow. the above suggestions (608, 609) did not seem to help. further suggestions?
|