- June 18, 2025, 18:21
- Welcome, Guest
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
1
Bug Reports / Re: [0.9.9.6G Windows] Client Glitches
« on: March 25, 2012, 15:55 »
Sounds like its possibly an issue with swapping in and out of the game using control escape or alt tab. Even in windowed mode, most games will have problems with the alt, control, or shift keys being stuck on when re-entering the game. Thus shifting/altering the inputs and in some cases simply making them not work at all.
Easy way to make sure thats not the case, and something ive trained myself to do, is to quickly hit shift, control, and alt once or twice every time ya swap back into a game.
Easy way to make sure thats not the case, and something ive trained myself to do, is to quickly hit shift, control, and alt once or twice every time ya swap back into a game.
2
Bug Reports / Re: [0.9.9.6G] Graphical movement lag unacceptable
« on: March 23, 2012, 11:09 »
First off, have to say that the new game looks amazing, good work. The new tiles are beautiful, and the custom cursors and things are a nice touch. (Though like most custom game cursors, they feel 'slower' than the standard windows cursor, and seem to operate on a small but noticeable delay, seeming to feel a few frames behind. Not sure if theres anything that can be done about that though aside from allowing the user to use the system default cursor.)
Anyway, im posting here because im having a similar issue to the thread starter in XP on an Intel Q9400 Quad core with 4 gigs of ram and a Radeon X1900. Have to agree with the other poster, that the unpredictable delay in 0.9.9.6g (sometimes its more, sometimes its less) does make playing with the keyboard very difficult, especially as you can easily get multiple moves ahead of the game display, meaning that by the time you see a problem, you've already walked multiple steps into it and cant stop.
It appears that theres a small delay after every movement animation, even on e1m1 with all enemies eliminated, perhaps removing/fixing this delay would help? Im not sure if this is for giving the AI time to move/update, or if its actually caused by slowness in the rendering, those would be my guesses though. It seems like there could be multiple ways (which will hopefully be presented as tweakable options) to fix the issue:
1: By speeding up the player movement and screen-shifting animations, or allowing the user to set how many frames of movement they want to see between each tile / allowing the them to disable it entirely.
2: By not allowing the game to queue multiple movements in graphical mode, requiring that the user wait for the animations to finish before being allowed to make another move.
Anyway, keep up the good work guys. While there are still some kinks to work out, theres no doubt about how visually polished the new release looks. As a result, i think it could easily bring in a lot of new players and supporters, and certainly hope it does.
Anyway, im posting here because im having a similar issue to the thread starter in XP on an Intel Q9400 Quad core with 4 gigs of ram and a Radeon X1900. Have to agree with the other poster, that the unpredictable delay in 0.9.9.6g (sometimes its more, sometimes its less) does make playing with the keyboard very difficult, especially as you can easily get multiple moves ahead of the game display, meaning that by the time you see a problem, you've already walked multiple steps into it and cant stop.
It appears that theres a small delay after every movement animation, even on e1m1 with all enemies eliminated, perhaps removing/fixing this delay would help? Im not sure if this is for giving the AI time to move/update, or if its actually caused by slowness in the rendering, those would be my guesses though. It seems like there could be multiple ways (which will hopefully be presented as tweakable options) to fix the issue:
1: By speeding up the player movement and screen-shifting animations, or allowing the user to set how many frames of movement they want to see between each tile / allowing the them to disable it entirely.
2: By not allowing the game to queue multiple movements in graphical mode, requiring that the user wait for the animations to finish before being allowed to make another move.
Anyway, keep up the good work guys. While there are still some kinks to work out, theres no doubt about how visually polished the new release looks. As a result, i think it could easily bring in a lot of new players and supporters, and certainly hope it does.
3
AliensRL / Re: opinions on 0.8 changes
« on: June 06, 2010, 15:59 »
Compared to what little i played of AliensRL before this new release, its become much more enjoyable to play. Not experiencing the lost ammo bug helps significantly. Like a lot of whats being done, only hope it continues to improve further.
Is there a way to scroll the display window? The look command only looks away from the player at a distance of about 10 squares or so. I run the game windowed in 1024x756, and this can make it a bit more difficult to see where ive been on a floor than if ran at a higher resolution. The lower tower levels appear to be about 80x80 and i can see 30x30 horizontally and 19x19 vertically at my resolution.
Also, is or will it possible to use a tilesets that are not 10x18 in size?
Is there a way to scroll the display window? The look command only looks away from the player at a distance of about 10 squares or so. I run the game windowed in 1024x756, and this can make it a bit more difficult to see where ive been on a floor than if ran at a higher resolution. The lower tower levels appear to be about 80x80 and i can see 30x30 horizontally and 19x19 vertically at my resolution.
Also, is or will it possible to use a tilesets that are not 10x18 in size?
4
Requests For Features / Re: Changing the colors for weapons to indicate whether they are loaded or not.
« on: April 17, 2010, 18:31 »
Its just more of an idea for an interface time saving and accessibility measure. IE when an item is already in your line of sight, you can Look at them which tells you how much ammo is in them, so why not just extend that one step further and be able to physically look at them on the screen to tell that they are different weapons (no possible confusion between pistol and double shotgun for example if they are different symbols/color groups) and if they are empty or not.
The two easiest ways of making more information more easily available to the player are by changing/adding colors, and changing/adding different symbols. Color tends not to add much complexity if applied properly, but more symbols to learn can be daunting to a new player and potentially detract from an experience. So its all about balance either way ya look at it.
Its obviously not a perfect proposal for a change, and would require a bit of work re-thinking character groups and colors. There are some downsides such as adding complexity if the number of characters a player needs to understand increase. DoomRL is a pretty simple game compared to other roguelikes, keeping it that way is important i think. Whatever changes may come from the idea will hopefully keep that in mind and add to the player experience and make discerning information easier, without adding unnecessary complexity.
The two easiest ways of making more information more easily available to the player are by changing/adding colors, and changing/adding different symbols. Color tends not to add much complexity if applied properly, but more symbols to learn can be daunting to a new player and potentially detract from an experience. So its all about balance either way ya look at it.
Its obviously not a perfect proposal for a change, and would require a bit of work re-thinking character groups and colors. There are some downsides such as adding complexity if the number of characters a player needs to understand increase. DoomRL is a pretty simple game compared to other roguelikes, keeping it that way is important i think. Whatever changes may come from the idea will hopefully keep that in mind and add to the player experience and make discerning information easier, without adding unnecessary complexity.
5
Requests For Features / Changing the colors for weapons to indicate whether they are loaded or not.
« on: April 15, 2010, 20:12 »
I was recently playing and thinking to myself 'its hard to tell the difference between a pistol and a double shotgun', as they all use the same character to display, and a similar color which is hard to distinguish at a quick glance.
My thought was that it would be nice if they all used a separate graphic/character that way you could use color to represent a loaded or unloaded pistol, shotgun, chaingun ect. I find myself constantly scavenging weapons, and then forgetting if i have already unloaded em, and then have to manually use the look command to check. The proposal would solve that problem by say using a lighter color for a partially/fully loaded weapon (more visible so it can be easily seen) and then a darker color of the same shade to indicate a fully unloaded weapon which would stand out less compared to the loaded ones.
Obviously there are problems with this idea, such as finding enough representative characters for each different weapon, and then using a dark and light color to represent unloaded/loaded that wouldnt conflict with some of the uniques and whatnot.
-
As a second part to this feature request, id like to see the list of items in the color.ini be somewhat less vague and incomplete. Adding the primary items/weapons/powerups/monsters (leaving out the spoilers/rares) you are likely to run into during the first few levels. It might also help to include the color that the items are by default, that way people could compare what they've already seen with how they want to change it, instead of having to trial and error till they find what they want. Also including a link to the relevant wiki page in the file would save people some trouble i suspect, myself included. >_<
Currently, i think that link is:
http://doom.chaosforge.org/wiki/index.php?title=Modding:sID and or http://doom.chaosforge.org/wiki/index.php?title=Item_IDs
EDIT: Removed question. The "entity IDs" apparently are apparently the 'Name' of the object and not the ID afterall. I tried searching for "item id" and "entity id" and similar stuff on the wiki but couldnt seem to find the right page. Strangely enough a search for "item ids" or just plain "item" results in the proper page.
Currently as of 0.9.9.1 the color.ini says:
// Custom coloring based on entity ID's. Search the DoomRL wiki
// for id's for entities. Colors can be:
// BLACK, BLUE, GREEN, CYAN, RED, MAGENTA, BROWN, LIGHTGRAY, DARKGRAY,
// LIGHTBLUE, LIGHTGREEN, LIGHTCYAN, LIGHTRED, LIGHTMAGENTA, YELLOW, WHITE
[Colors]
// pistol = "MAGENTA";
// former = "GREEN";
Would appreciate feedback on the idea, and any question answering you guys can do. :)
Thanks.
My thought was that it would be nice if they all used a separate graphic/character that way you could use color to represent a loaded or unloaded pistol, shotgun, chaingun ect. I find myself constantly scavenging weapons, and then forgetting if i have already unloaded em, and then have to manually use the look command to check. The proposal would solve that problem by say using a lighter color for a partially/fully loaded weapon (more visible so it can be easily seen) and then a darker color of the same shade to indicate a fully unloaded weapon which would stand out less compared to the loaded ones.
Obviously there are problems with this idea, such as finding enough representative characters for each different weapon, and then using a dark and light color to represent unloaded/loaded that wouldnt conflict with some of the uniques and whatnot.
-
As a second part to this feature request, id like to see the list of items in the color.ini be somewhat less vague and incomplete. Adding the primary items/weapons/powerups/monsters (leaving out the spoilers/rares) you are likely to run into during the first few levels. It might also help to include the color that the items are by default, that way people could compare what they've already seen with how they want to change it, instead of having to trial and error till they find what they want. Also including a link to the relevant wiki page in the file would save people some trouble i suspect, myself included. >_<
Currently, i think that link is:
http://doom.chaosforge.org/wiki/index.php?title=Modding:sID and or http://doom.chaosforge.org/wiki/index.php?title=Item_IDs
EDIT: Removed question. The "entity IDs" apparently are apparently the 'Name' of the object and not the ID afterall. I tried searching for "item id" and "entity id" and similar stuff on the wiki but couldnt seem to find the right page. Strangely enough a search for "item ids" or just plain "item" results in the proper page.
Currently as of 0.9.9.1 the color.ini says:
// Custom coloring based on entity ID's. Search the DoomRL wiki
// for id's for entities. Colors can be:
// BLACK, BLUE, GREEN, CYAN, RED, MAGENTA, BROWN, LIGHTGRAY, DARKGRAY,
// LIGHTBLUE, LIGHTGREEN, LIGHTCYAN, LIGHTRED, LIGHTMAGENTA, YELLOW, WHITE
[Colors]
// pistol = "MAGENTA";
// former = "GREEN";
Would appreciate feedback on the idea, and any question answering you guys can do. :)
Thanks.
6
Bug Reports / Re: [0.9.9.1] (Win) direct rocket hit without damage
« on: April 07, 2010, 11:42 »
I experienced this on angel of max carnage hey not too rough difficulty. I had a power modded missile launcher, and was fighting the two brothers. After 3-4 hits to each, one of the brothers was scratched, and the other was unhurt.
7
Bug Reports / [0.9.9.1] (WinXP SP3) Chainfire, color bugs, and questions.
« on: April 04, 2010, 19:45 »
First off i just want to say that this is an amazing little game, ive had fun with it. Now id like to talk about some bugs ive discovered that i didnt see mentioned on the forums.
1: When chain firing a chaingun or plasma rifle, a single tile becomes colored yellow in the lower right hand side of the map while chainfiring. It appears 10 squares away from you diagonally down and to the right. In order to make it appear you usually need to be in the upper-left side of the map and have a valid monster targeted when you do the initial chain-shot.
2: When colorizing text, the text does not always colorize the full sentence. When the line breaks to the next line the phrase loses its color. Often times only one or two words will be colorized. Example below:
Fire -- Choose target... The missile hits the former sergeant. The
former sergeant dies. <--- Loss of color.
(It should look like: The missile hits the former sergeant. The
former sergeant dies.)
3: When using the "Light" colors (LightBlue, LightCyan, LightGreen, LightMagenta, LightRed, LightGray and Yellow) the text always appears as white on the bottom line of the main screen, on the top line it appears to be the color that it should be.
LightGreen_1: "* hits you.";
The former human hits you! <--- Proper LightGreen on the top line and in the message log.
The former human hits you! <--- White, not Green on the bottom main-screen line?
4: When using the normal colors (Blue, Cyan, Green, Magenta, Red, and Brown) the color appears as its 'bright' counterpart on the bottom line of display, and then on the top line and in the log it is dimmed and appears as its normal/dark color.
RED_1: "* hits you.";
The former human hits you! <--- Proper Red on the top line and in the message log.
The former human hits you! <--- LightRed, not Red on the bottom main-screen line?
I would like to use the LightColors for some stuff, but since they all display as white on 1/2 of the main screen they dont catch the eye, and are only useful for the message log. :\
5: The color Black_1 crashes the game when used in the DoomRL.ini even though the color.ini file has Black listed as a valid color.
-
Questions about coloring messages in the DoomRL.ini file:
6: Is it possible to color a single word? Like: The former human hits you!
7: Is it possible to use multiple colorizations for a phrase? Using one color to color the phrase, and another to color a specific word:
BROWN_1 = "The former human hits you!"; and then using RED_1 = "hits";
The former human hits you!
Thanks!
1: When chain firing a chaingun or plasma rifle, a single tile becomes colored yellow in the lower right hand side of the map while chainfiring. It appears 10 squares away from you diagonally down and to the right. In order to make it appear you usually need to be in the upper-left side of the map and have a valid monster targeted when you do the initial chain-shot.
2: When colorizing text, the text does not always colorize the full sentence. When the line breaks to the next line the phrase loses its color. Often times only one or two words will be colorized. Example below:
Fire -- Choose target... The missile hits the former sergeant. The
former sergeant dies. <--- Loss of color.
(It should look like: The missile hits the former sergeant. The
former sergeant dies.)
3: When using the "Light" colors (LightBlue, LightCyan, LightGreen, LightMagenta, LightRed, LightGray and Yellow) the text always appears as white on the bottom line of the main screen, on the top line it appears to be the color that it should be.
LightGreen_1: "* hits you.";
The former human hits you! <--- Proper LightGreen on the top line and in the message log.
The former human hits you! <--- White, not Green on the bottom main-screen line?
4: When using the normal colors (Blue, Cyan, Green, Magenta, Red, and Brown) the color appears as its 'bright' counterpart on the bottom line of display, and then on the top line and in the log it is dimmed and appears as its normal/dark color.
RED_1: "* hits you.";
The former human hits you! <--- Proper Red on the top line and in the message log.
The former human hits you! <--- LightRed, not Red on the bottom main-screen line?
I would like to use the LightColors for some stuff, but since they all display as white on 1/2 of the main screen they dont catch the eye, and are only useful for the message log. :\
5: The color Black_1 crashes the game when used in the DoomRL.ini even though the color.ini file has Black listed as a valid color.
-
Questions about coloring messages in the DoomRL.ini file:
6: Is it possible to color a single word? Like: The former human hits you!
7: Is it possible to use multiple colorizations for a phrase? Using one color to color the phrase, and another to color a specific word:
BROWN_1 = "The former human hits you!"; and then using RED_1 = "hits";
The former human hits you!
Thanks!
Pages: [1]