Various Reasons
#80 posted by Baker on 2017/01/04 21:24:19
a) For original experience at map release time as an option.
b) Testing and checking for a material behavior difference.
c) Fallback if something if bug or issue with current version, without the user having to reinstall an older Quoth to work around it.
I know some of the mild changes like changing the voreling health don't mean much to most people.
But for instance, if I want to reply an old map that I liked, I'd like to easily replay it with exactly the same rules and behavior in effect that were there the first time. At least as an option.
What if I want the voreling to be annoying and require 2 super-shotgun blasts to kill because when I played the map originally it had annoying vorelings?
One irony is that certain releases are actually mostly exempt from Quoth upgrades because they have their own progs (Metal Monstrosity, for instance).
@preach
#81 posted by Baker on 2017/01/04 21:25:53
Also what Pritchard said.
You pioneer the incremental mod release idea with the additive pack concept.
If others follow your lead, my above scheme is a way that full compatibility is always an option.
@preach - Issue Example
#82 posted by Baker on 2017/01/06 00:31:36
1) I take warpspasm.zip from Quaddicted.
2) I take Quoth 2.2.2 zip which I am assuming is current version 8,035,386 bytes (pak2.pak size, working on assumption that the date of May 3 2014 is error of the zipping tool).
3) Using the glwarp.exe provided with the Warpspasm download I do this
...
c:/quake/glwarp.exe -game warp -quoth
What I get when I startup
*) I get Quoth demos playing.
What I am supposed to get when I startup
*) I should get the Warpspasm start demos playing.
Basically, playing Warpspasm with current Quoth I can't get the intended Warpspasm experience.
(I wouldn't have to use glwarp.exe, I could instead use Mark V or BengtQuake or the Requiem engine --- all which support the Warpspasm demos that are in protocol 10002.)
So anyway, an example.
Backwards Compatibility
#83 posted by
Preach on 2017/01/13 23:48:27
I have responded in much more complexity than was perhaps necessary
here
#84 posted by Baker on 2017/01/14 00:00:01
I think that is a cool thread.
Anyway, I think a "Touch of Evil" is going to be my in-engine short-term solution for the Warpspasm issue to make it so the presentation is right ...
if (game == warpspasm && command == startdemos)
... if (startdemos != "demo1 demo2 demo3") then make it so
You are happy. I am happy. Someone wanting the Warpspasm experience is happy.
Somewhere an Evil God of Proper Coding is looking down at me with a frown --- but that happens all the time.
/Quoth 2.2 at Quaddicted on last check is still 2.2.1, btw. I checked rather recently and the byte size of pak2.pak is not same as your Quoth 2.2.2.
#85 posted by
ijazz2 on 2017/01/18 18:21:43
So when's Quoth 2.3 coming out?
Skybox Format
Is
this the same format and orientation for the skyboxes in the Quoth pak files? Or are some of the locations different? I thought I'd ask as I don't have a ton of time for trial and error. The one time I've tried it was a disaster.
I would like to do my own from
Space3d
Non-domain
#87 posted by
Preach on 2017/07/02 18:07:13
This is really more of an engine thing than a Quoth specific question, but I think I have figured it out. If you change the filename suffixes in the following way everything should align:
pos_y -> up
pos_z -> bk
pos_x -> rt
neg_z -> ft
neg_x -> lt
neg_y -> dn
#88 posted by Spike on 2017/07/02 20:00:40
lt+rt are flipped in relation to normal cubemaps, iirc.
this means that the other 4 images are flipped on various axis too or whatever, which means simple renaming isn't exact.
If you don't really care that your cubemap is basically inside out then whatever just go ahead and rename them, but if you want to map them exactly then you need to do more than just rename them. Probably for embedded space scenes you won't care.
@spike & @Preach
Thank you guys so much. I was just sitting down to do a simple number 1-6 cubemap in PS to see what could be flipped etc. This helps a lot.
Confirming Skybox
pos_y -> up
pos_z -> bk
pos_x -> rt
neg_z -> ft
neg_x -> lt
neg_y -> dn
Tested in Quakespasm - this is the right configuration! Thanks again.