 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
I'm pretty sure that iw's point about texture name is valid. Current sky texture name has fixed size (32) and is copied using strcpy from a buffer of an unbound size (value of "sky" key). Whether this problem occurs or not is not bound to what platform you're on but rather how lucky you are. Layout of data in memory isn't necessarily the same from machine to machine (or even between OS restarts) and if you overrun a buffer, you may get lucky and overwrite nothing important. Of you may overwrite some super important state and application crashes. The fact that this happened to one of 5-ish people who played this map so far indicates that this will be hit by other people once you release the map.
Don't know if want these or not but here they are: Demos
Time was ofc shorter but still lengthy, coming in at almost 2 hours(117:35). As far as should it be broken up into multiple levels... hrmmm... I don't know, time is time. If a player can't play this for the total time then it will be a several sessions playthru regardless. Anyways, hth's I expected I would have had time to revisit the map before now, but I've had a busier week than anticipated. I should be able to replay it this weekend and come back to you with those remaining bits of feedback. Apologies for the delay.
About the sky path issue: I usually use Linux myself, however I was testing on an OSX box when I encountered the problem (using the 0.93.1 SDL2 binary from the QuakeSpasm web site). What Thulsa said above is very much what I was thinking: it looks like the buffer overflow will occur regardless of platform (it involves the skybox_name array in gl_sky.c), but because this is a low-level problem, what actually happens next would depend on various low-level things, which will presumably be different for different players running the engine on different platforms. In addition to Thulsa's examples, another factor is that different compilers may or may not emit additional machine code to try and automatically detect buffer overflows (depending on the options they're run with). I suspect that this might be what's going on with the OSX client, because I noticed that it keels over with SIGABRT instead of the usual SIGSEGV; however, like I said before, I just haven't had the chance to look into this in detail. BoraxMan, I should emphasize that I'm not saying this is a bug in your map. Assuming what I've said is correct, it's a bug in the engine; however, it's the sort of bug I guess mappers will want to work around. A very similar issue affecting other maps is the crash-on-save bug I talked about in this post. Like this issue, the save bug doesn't cause the engine to die immediately for all players on all platforms; however, it evidently has that effect in a lot of cases (judging by the number of comments about this on map pages on Quaddicted). OK, I've played through locbeta again, on skill 3 this time. I recorded a bunch of very short demos showing specific bugs, which I've uploaded here. While recording these, I couldn't recall exactly which bugs were visible in my previous demos and which weren't, and when in doubt, I thought it was best to risk recording the same thing again, so there's likely some duplication.
I think the demos will be self-explanatory, so, here's some more general feedback about the map: I liked the following: * It has a strong, consistent theme. I liked the feeling of wandering through this sprawling otherworldly nightmare-palace where everything was menacing and malevolent at all times. * I especially liked that there are creepy side-areas in various places which the player can see into but can't enter. Like the yellow-lit room with the Shambler corpse. I'm a big fan of levels including environmental details for no other reason than to be creepy and build atmosphere. * The "hallucination" sequence (I'm not sure what to call it) actually spooked me on my first playthrough! I think that was because it was so unexpected. * The hugeness of the map, when it starts opening out, is impressive in its own right. * The scale of the environment and the lack of repetition in the design reminded me of things like WarpSpasm and various huge Tronyn maps. I don't think the large size of the map is a bad thing in of itself. But I obviously found the layout and progression pretty difficult, and I think the large size of the map probably exacerbated that. I've been trying to put my finger on why I found the layout/progression difficult. I don't think it's one thing, but a combination of several different things: * At any one time there are a lot of different barriers (bars, force fields, key doors, etc.) which I have to try and remember so I can find my way back to them once I've found the thing that opens them. * Some important barriers are not on the main path and are easy to overlook. An example is the gold key door: it's a long-term objective that the player will have to return to later, but it's in a side-area the player can easily miss. * In some cases I found the means of opening a barrier without having encountered the barrier itself (leading to a feeling of "so where do I go now?"). * Even when replaying, I found it easy to forget which number Lord I was up to (which is obviously important because the hint messages refer to them by number). I also found it easy to forget whether I was supposed to be hunting for a Lord at any given time. Even though I don't think the size is the problem, if you're in a mind to split the map in two, I guess that might mitigate the above issues? I can't help thinking I would have enjoyed the map more if I didn't have to hunt for the Lords after summoning them. When trying to find them, I just felt like I was wandering aimlessly. About the ammo situation: I found the ammo shortage at the start a bit irritating, especially as the player is confronted with gangs of bullet-spongey Fiends and Ogres right off the bat. I would have preferred a more "normal" ammo balance at the start. From about the halfway point, the ammo balance seemed to have become more normal anyway. (Disclaimer: I've only played on skill 2 and 3.) But apart from those things, I definitely enjoyed the map. Whether you decide to split it into two maps or not, I'd be curious to play the next version to see how it's evolved. Hello there!
I've uploaded the first alpha version of my new dev kit CPQ and am very much looking for some feedback on it. CPQ is all about storing values into "registers" and then using them to impact the game (changing player health, door speed, etc) as well as boolean expressions (greater than, less than...) that can trigger different things when true/false, as well as mathematical operations (multiplying enemy health by difficulty level, for example). I've included a map that shows off some features, as well as PDFs that give a quick tutorial and list all new entity definitions. Downloads: Quaketastic Google Drive Feel free to reply me here or PM on Discord (Qalten #6722) with feedback/errors/suggestions/neat maps! Why CPQ? Because it sounds like CPU but with a Q! (a CPU being more or less what I'm trying to emulate here). my vote for unsung hero. this looks like it can be insanely useful, but I find the presentation a bit impenetrable. but seriously, having a simple way of doing arithmetic and boolean expressions without needing counters or relays sounds awesome.
Been putting lots of time into the side scroller. Heres some new tiles.
https://twitter.com/muk0r/status/1212905762038657024 I like the weird lack of head. Claws could look a bit more inhuman. Deffo could work well in Quake.
http://shoresofnis.com/temp/Screenshot_Doom_20200113_195048.png
not sure if this would have been easier or harder in quake. i will say the doom engine handles off-axis stuff nearly perfectly. did Q1 compilers ever get around the limited number of planes? |
|
|
|
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |