Chaosforge Forum
DoomRL => Bug Reports => Topic started by: singalen on August 30, 2013, 23:53
-
I pushed several barrels across a bridge, and one barrel started to paint tile it was on into a tile it's being moved onto.
-
Known bug. Not sure how we're going to fix it. It has something to do with how the tiles are tracked internally.
Since this stomps on the Pascal side, we're probably going to wait for Kornel to decide how to fix it.
Thanks for the report though.
-
I think the problem here is that barrels are considered tiles for some reason, so "moving" them actually swaps barrel tile with one in the direction you're going. The solution would be to change them to items, like teleportation portals are - seems to me like it'd work based on my limited understanding of game's inner workings.
-
It's actually the same problem as how moving the barrel across a bridge screws up the bridge in console mode.
I dunno... we can try a fix and see how it works out in 0.9.9.8 beta.
-
This has to be the most re-reported bug in the history of DoomRL...
and I think I posted this same thing the last time it was reported!
-
Yep. I know I've reported this at least once.
-
It should be marked as "will-not-fix" - this would require implementing another map layer especially for barrels, which in turn would require a lot of bug testing, which in turn would take a lot of time for a little gain. Time that could be better spent implementing new cool stuff.
-
I'm still having trouble understanding why barrels can't be handled the same way as teleporters. As far as I remember from my modding days teleporters are ITEMS placed on CELLS. They use OnEnter to do the teleportation - some additional tweaking might be needed to use that for moving them by triggering OnEnter but it doesn't look like it'd be "new layer just for barrels" level of complexity to add. And as items can already be destoroyed the "blow the barrel" part should be doable as well.
Am I missing something obvious here?
-
You can't shoot or push items. And it would be a lot of work, however you decided to tackle it, to fix the issue properly.
We could probably fix it improperly if nobody minds some egregious hacks :)
-
Being a total layman as to how this has been implemented, this just occurred to me: if the tiles are indeed swapped, as Malek suggests, can't you insert some kind of cross-reference mechanism? You number your tiles xxy with xx being floor type and y being barrel type (none/fuel/acid/BURNINATION) and compare tile numbers on swap. Source(xxy) becomes source(xx&destination(y)) and destination(xxy) becomes destination(xx&source(y)).
Ten to one someone's already tought of this, though...
-
That's a quickfix I thought about. Make several types of barrels (barrel-on-floor, barrel-on-bridge) and change them on the go.
-
That would work but it would require defining a lot more cells--4x as many floor cells--to store the extra information. A pseudo-layer (a sparse array) that tracked the barrels as they are generated and moved would be easier and is probably the least hacky quick fix available.
-
(never mind)
-
Aren't there only 2 floor types a barrel can be pushed onto?
I don't think a specific barrel layer is less hacky: it's a whole new data structure, it requires separate maintenance (both at run time and in coder's time), and it won't be exposed to Lua.
-
...and now that bad game design decision (barrels-as-floor-tiles) will haunt game forever. :(
-
Could be worse.
Could be raining.
-
Just make a barrel remember what type of floor tile it's standing on, restore when moving. That's how I'd do it...
(well, at least that's a quicker fix than changing the nature of a barrel :P)
-
Cells cannot 'remember' anything. They are not distinct objects.
-
The level data could... if we wanted to. But it'd be specific to barrels and doors (and maybe floor/liquid edges?), and add an entire extra map layer. I don't think it's worth our time just yet, as KK said.
-
Well, considering that 0.9.9.8 is largely going to be a while away, and we don't really have anything major planned for the code... we can probably visit this.
Maybe we should start a thread on the Tavern for 0.9.9.8 planning/execution to keep KK informed of what we're doing while not increasing his cognition overhead.
-
Or we could just keep this bug in here forever and build a mythos around it. Start a pool on when it's going to be changed. Tie it to picking up the DS. And finally, create achievements for folks who manage to relocate the entire bridge elsewhere.
-
Maybe we all are coming to it from wrong direction?
My proposition: do away completely with barrels as special floor tile. Implement them as "Monsters" with very specific AI and attributes.
This AI and attributes will ensure they will not move, will not count in kills, are pushable, explode when die, etc etc - and hopefully not everything in same attribute isBarrel or something equally shoddy. I would want to allow, for example, exploding monsters on kill.
It would allow for:
- Elimination of most often reported bug in history of DoomRL. Sorry, this cannot be left as is.
- Having many various background tiles (currently default + bridge, water/acid/lava tiles are special case) in future versions of DoomRL. Without this fix, it will get only worse in future.
- Allows pushing barrels over water, flooding level with water does not leave islands with barrels on them, allowing barrels to survive a while on acid (push run away, watch monsters go boom) etc.
- Easy "exploding monsters" for modders.
Surely it is less work than some unneeded level layer just for barrels?
-
"Monsters" with very specific AI and attributes.
OK, and how many times are you going to go for YAAM on a level filled with napalm barrels?
-
OK, and how many times are you going to go for YAAM on a level filled with napalm barrels?
will not count in kills
I like this, depending on the code. You need to change "bump against" behavior based on target 'monster'. Door?/Barrel open/push vs melee strike against all other monsters. Should be easy to do I think.
-
depending on the code
That's just the thing: there's a lot of different possible solutions, all with their pros and cons, but it all depends on how everything's set up to interact. Since moving into a monster and moving into a barrel yields completely different results, I'm willing to bet that no pushing mechanism is in place for this type of interaction, for starters. And there's more of course, such as the kill % and stuff I'm likely to be completely overlooking.
Mader may have handed us the solution, but it's the four words you just wrote down that make all the difference.
Either way, don't feel deterred by me; please keep spewing ideas. Who knows what may lead to the eventual solution...
-
OK, and how many times are you going to go for YAAM on a level filled with napalm barrels?
I directly mentioned that barrels will not be counted for kills.
will not count in kills
I have impression you just read big yellow text and nothing more.
Since you expressed doubts about it, lets talk about needed changes in relation to regular monster...
- Cannot move or notice player. In fact, it would be perfect monster for "sessile AI". Moders could have other uses of such AI, I imagine.
- No sounds (except barrel explosion).
- Does not contribute to kill count.
- Does not give exp.
- When dies, explode.
- When dies, spawn nothing/acid/lava.
- Pushable.
Additionally, three kinds of "barrel monster" exists - normal, acid and lava barrels.
Other interactions to consider:
- Of course, spawning of barrels on map would have to be redone.
- Can we allow spawning barrel on item? What about pushing barrel on item with or without moving them? I personally do not see any problems with it. Imagine RAEG of player that see barrel in map corner standing on invul sphere. :3
- Interaction with harmless terrain: water, doors. Note this can make game a little easier, as you now can in most case move barrels around entire level - you can push them through door or river.
- Interaction with other terrain: acid, lava.
I am certain there are more interactions that need to be addressed, but I do not think it is anything particularly hard to implement.
-
Heh. If you don't want to draw attention to the big yellow text, don't make it big and yellow to begin with -- a normal bold form of text is enough to draw sufficient attention without drawing all attention to it only.
At the risk of sounding condescending, please don't make claims that "it should be easy to implement" or "not particularly hard to implement" or "probably a couple of lines of code". We like suggestions on solutions, but please let us figure out if something is feasible based on our experience with the code base. I don't know and don't care how many years of experience one has in programming, or how many AAA-listed programs one has written, but when it comes to any particular program, the specifics are always different, so please allow us to use our professional understanding of the current code base to decide the ease of coding up something.
We like bug reports, we like suggestions, but we dislike getting told implicitly that we're dumb and can't even think of the "obvious" solution. Let's keep things constructive here. =)
-
@Mader, I actually did read the rest of the post, but not well enough, it appears. My comment on it wasn't meant to dismiss your idea either, but more to paint the mental picture of Doomguy running through Hell on a YAAM attempt and running into a total deathtrap in this fashion. In my head, I could see his adam's apple doing a nice little acrobatic number :)
I have to agree with thelaptop in your use of formatting, though; using it like this makes it very easy to start overlooking other stuff in your post.
-
Fixed text per your suggestions, as it was unintentionally distracting.
We like bug reports, we like suggestions, but we dislike getting told implicitly that we're dumb and can't even think of the "obvious" solution.
It was not my intention implying anyone is "dumb". Sorry if I gave that impression.
-
Nah, don't sweat it. You're new on the forums -- we like the enthusiasm, but we also appreciate more if you could lurk a little more before posting.
=)
-
Abusing enemies in order to make them immobile barrels would be a lot of work and I'm not 100% certain it could be done. That's the sort of exploitive coding crazy modders do, not the sort of thing the game and engine proper should do.
I'm of the opinion, but I'm not sure if it is well shared, that if this does get fixed it should be fixed by the fan crew properly once DoomRL reaches the end of its shelf life.
-
but I do not think it is anything particularly hard to implement.
I found a nice answer to such a recurring opinion. Compared to regular AAA games (let's say Quake 3), how big do you think DoomRL's source is?