this might not be the right place for it, but can I get access to the bsp2-supporting compilers and version of the RMQ engine? Or rather when can I get access to this, I REALLY suspect that bsp2 will be necessary for the map I'm working on now. Are you guys going to at least release this stuff alongside the new demo? When's that out anyway ;)

I've always thought most of the maps in Zer are not that great, but the graveyard map was good, True Love Waits ruled, and the story/ending was good. It's more about the coherence of the pack as a whole. 

...that consists of a load of completely random items and maps cobbled together with the only thing in common being the gloomy black sky??

;) 

I hate that argueing about quake levels that were/are will not be good enough, as it makes no sense in the time they were made other standards counted than nowadays ...

I was already glad I could snatch a level from the net and play it!

It was in the time of the bad quake levels new ugly layout apeared and parasites didn't ask your pardon to enter their godnow how level

hm, sorry for that. 

It was in the time of the bad quake levels new ugly layout apeared and parasites didn't ask your pardon to enter their godnow how level

What's this supposed to mean?? 

 

sorry for that already, so it wasn't ment to someone.
just overread my blashphemy as my thought to the subject itself.

Is that blashphemy? 

What does it mean, as in, I genuinely didn't understand it at all. Sorry for the confusion! 

Tronyn: I believe MH wants to put off an official release because of the format's unfinished / may-change-if-necessary nature. That means there could be conflicting versions very quickly, in the worst case.

However, it is probably beneficial to have more people use BSP2, simply to see if the limits are high enough :-P I know that at least Ajay over at i3d has a map that breaks the old BSP format, and maybe Necros will benefit from this as well.

MH is the one who eventually calls the shots on this issue though. Then again, MH is probably still glued to the screen playing Rage ;-)

Basically, everyone who uses BSP2 at this time must understand that it isn't final and it would probably be a good idea to release your map sources for any BSP2-using project (so it can be recompiled should the format change later).

I trust Louis e-mailed you the stuff now? That's not to say you couldn't simply get it from the SVN, of course. ^^ However, that's an effingly huge download and requires SVN, so you might prefer a zip file. XD

Anything about any demos being released anytime is sort of depending on if anything gets to any presentable level. It's also debatable if the demo format still makes sense when there is an SVN repo. Needless to say, anything from any SVN might break without warning at any time, of course, while a demo release would hopefully - ideally - be a lot more tested and polished and bear a stamp saying "teh official".

I believe some of ijed's maps are closest to being presentable right now (e3m3rq?), but we're in the middle of a dev cycle atm. e1m2rq was close, but I've since decided to brutally rip the lid off and really test BSP2, so I won't have something to show for a while longer. Ricky's e2m1rq might be another candidate, but IIRC he said he wanted to add more details still.

Our dev cycle ends shortly before Xmas, so it's unlikely that any release is made before then. There was a little downtime recently due to the move to icculus.org and everyone playing games instead of slaving properly. ;-)

As for new Zer content, yes please! I must admit that I don't think RMQ is the right platform for it though. However a dedicated modder could probably create an updated Zer SDK by ripping and porting code from RMQ and maybe Drake. For example the stuff from RMQ's proto-shalrath (magic system) could be backported to the zer troglodyte eventually. Open source is a good thing.

>>> RMQ is intended to be fair game to borrow stuff from for other mods. We borrowed from others ourselves. Crossbreeding between mods is healthy for the community - it used to be done all the time. Please help yourselves to the goods.<<< 

Ive been away for a week and am just on my way back now. I hope to have multiple betas ready for this xmas deadline. As for BSP2 its functional for now, releasing a test version is fine by me.

Will try and get you a version tonight. 

Anyone else want a look at the tools?

I'm reluctant to post them officially for now, but a couple of betatesters would help, in preparation for the xmas deadline. 

The Y-Axis for rotation appears to be reversed in RMQe?

ie: in all engines except RMQe, an increase in .angles_y yields a clockwise motion when looking up whereas the same in RMQe produces a counterclockwise motion.
or am I hallucinating? 

iirc someone on the rmq team said they were aware of it. 

oh never mind, it's fixed in the new version.
also, dynamic lights work on bmodels that have moved off the origin, awesome! 

That was a small-ish thing that was easy to do and I felt it was important enough to get right. It ended up as maybe 5 lines of code, and should probably be tutorialized for I3D sometime. 

 

is vectoangles() somehow returning lower precision angles than the rest of the engine? seems like when i use that, i get the old style jerky movement. 

Shouldn't be, nothing specific changed in relation to it. 

ok, i'll look into it more then. for some reason, one of my rotaters looks like it's not benefiting from the new angles precision while other rotaters are and only in RMQe. 

That's odd. If you're happy to send me a test map I can look into it engine-side too. 

not to be a dork, but are you sure vectoangles is returning higher precision angles?
a quick bprint of angles from a vectoangles call shows that rmqe is rounding them to the nearest whole number (like QS does) while DP/QBism is returning decimals. 

Done 

awesome! 

You're actually right, it is casting them to int. That's original code too - why on earth was it originally done that way? Nasty; OK, going on the "fix list" immediately. 

RMQe, like QS and FQ doesn't seem to flush sound names between maps.

If you load up one map with many sounds and then load up another map with many sounds, the engine will crash with "S_FindName: out of sfx_t"

just in case you miss this in the other thread. :)