- Welcome to Knights Forum.
Recent posts
#61
Knights Discussion / Re: BMP Unsupported header siz...
Last post by d.healey - September 15, 2017, 04:30:29 PMNot yet, I haven't had time to have another look at it, I did make a wand of invisibility though :)
#62
Knights Discussion / Re: BMP Unsupported header siz...
Last post by Stephen - September 14, 2017, 06:25:00 PMDid you get anywhere with this?
#63
Knights Discussion / Re: BMP Unsupported header siz...
Last post by d.healey - September 07, 2017, 09:49:35 PMThanks, I shall have a play around with
#64
Knights Discussion / Re: BMP Unsupported header siz...
Last post by Stephen - September 07, 2017, 08:43:02 PMI wrote my own BMP loading code (some years ago now...) and it doesn't support all possible BMP formats, only the most common ones (or at least, what was common in 2008 :) ). It seems that GIMP is saving in a format that Knights doesn't support.
There are 3 answers:
1) Extend the Knights image loading code to handle other types of BMP file (see load_bmp.cpp)
2) Use an image loading library (SDL_image maybe?) instead of my hand coded image loader (probably a good idea to be honest, but will require some work)
3) See if we can persuade GIMP to save in a form that Knights supports. I would try the "Do not write colour space information" option in GIMP and see if that does it. (You have to go to File -> Export, save in bmp format, then open up Compatibility Options.)
There are 3 answers:
1) Extend the Knights image loading code to handle other types of BMP file (see load_bmp.cpp)
2) Use an image loading library (SDL_image maybe?) instead of my hand coded image loader (probably a good idea to be honest, but will require some work)
3) See if we can persuade GIMP to save in a form that Knights supports. I would try the "Do not write colour space information" option in GIMP and see if that does it. (You have to go to File -> Export, save in bmp format, then open up Compatibility Options.)
#65
Knights Discussion / BMP Unsupported header size
Last post by d.healey - September 06, 2017, 09:25:53 PMI'm having a go at creating a wand mod. I've edited the graphics in GIMP and exported as BMP but when I run knights it says unsupported header size. Any ideas?
#66
Knights Discussion / Re: Dagger hotkey
Last post by K9 - August 23, 2017, 08:57:15 PMSame here Stephen... Thank you for exceptional coding tips on this subject of controls and routines to explore, and your open source, site content and more.
+
Addendum, unrelated to above topic...
Been a long time since last met you in the dungeons, but I'm always thinking about you, grateful for all you've done, and doing to keep the server active for loyal fans (Moo, ImpassIve & myself routinely in Saturday/weekend quests) and great to see you're still in tune with quick response on forum.
I definitely relate to being busy, see you around.
+
Addendum, unrelated to above topic...
Been a long time since last met you in the dungeons, but I'm always thinking about you, grateful for all you've done, and doing to keep the server active for loyal fans (Moo, ImpassIve & myself routinely in Saturday/weekend quests) and great to see you're still in tune with quick response on forum.
I definitely relate to being busy, see you around.
#67
Knights Discussion / Re: Dagger hotkey
Last post by d.healey - August 13, 2017, 03:39:17 PMThanks for the detailed info. I shall spend some time now getting to grips with the code.
#68
Knights Discussion / Re: Dagger hotkey
Last post by Stephen - August 13, 2017, 03:17:58 PMWell, there is the Controller base class and an implementation for KeyboardController. (There was originally going to be other implementations for things like joysticks or gamepads, I never got around to that though.) This basically just gives you up/down/left/right and "fire button" functionality and mostly relates to the old style (original Amiga knights) controls.
The mouse controls (the "action bar" thing that you click on using the mouse) got added later, and this is partly implemented in the ActionBar class and partly in LocalDisplay::readControl.
The main logic for controls is in LocalDisplay::readControl so that's probably what you need to read if you want to understand how controls work.
There is also a UserControl class -- a UserControl represents something you can do in the game, like moving, or swinging a weapon, or picking up an item. (Or throwing a dagger.) Each UserControl has various pieces of information attached to it:
- the id number, which (I think) is used by the game engine to match the UserControl up to the actual code that executes the action.
- the "menu graphic" which is the icon that appears on the action bar (or the menu if using old style controls)
- the "menu direction" which controls where it appears on the old style 4-way menu
- the "tap priority" which I think controls what happens when you just tap the fire button (this is context sensitive so the highest priority action is selected)
- the action bar slot and priority, which controls where it appears on the action bar
- whether it is continuous (like lock picking) or not (like opening a door)
- the name (which acts as a "tool tip" if using the action bar)
- a couple of other things which I can't remember what they do now.
The UserControl instances are configured in Lua scripts, have a look at controls.lua and items.lua (they are hidden somewhere under the knights_data/server directory).
The responsibility of LocalDisplay::readControl is to look at the player's control inputs (keyboard, mouse etc) and work out which UserControl (if any) should be activated as a result.
The actual UserControl that LocalDisplay::readControl selects from are set up in two places:
- LocalDisplay::setAvailableControls is called by the game engine to notify it of which context-sensitive controls (such as opening a chest) are currently available.
- There is also a set of "standard_controls" (such as movement) that are always available.
Anyway, I guess that's some info about how the code works...
Note that the current Controller interface assumes there is only one fire button. An idea I had a long time ago was to have a "two fire button" system. The first button would be for "melee attack" (so swing your sword, axe or hammer) and the second would be "missile attack" (so either throw an axe, shoot a crossbow, or throw daggers depending on what the player has available). Maybe now is the time to look at implementing that...
The mouse controls (the "action bar" thing that you click on using the mouse) got added later, and this is partly implemented in the ActionBar class and partly in LocalDisplay::readControl.
The main logic for controls is in LocalDisplay::readControl so that's probably what you need to read if you want to understand how controls work.
There is also a UserControl class -- a UserControl represents something you can do in the game, like moving, or swinging a weapon, or picking up an item. (Or throwing a dagger.) Each UserControl has various pieces of information attached to it:
- the id number, which (I think) is used by the game engine to match the UserControl up to the actual code that executes the action.
- the "menu graphic" which is the icon that appears on the action bar (or the menu if using old style controls)
- the "menu direction" which controls where it appears on the old style 4-way menu
- the "tap priority" which I think controls what happens when you just tap the fire button (this is context sensitive so the highest priority action is selected)
- the action bar slot and priority, which controls where it appears on the action bar
- whether it is continuous (like lock picking) or not (like opening a door)
- the name (which acts as a "tool tip" if using the action bar)
- a couple of other things which I can't remember what they do now.
The UserControl instances are configured in Lua scripts, have a look at controls.lua and items.lua (they are hidden somewhere under the knights_data/server directory).
The responsibility of LocalDisplay::readControl is to look at the player's control inputs (keyboard, mouse etc) and work out which UserControl (if any) should be activated as a result.
The actual UserControl that LocalDisplay::readControl selects from are set up in two places:
- LocalDisplay::setAvailableControls is called by the game engine to notify it of which context-sensitive controls (such as opening a chest) are currently available.
- There is also a set of "standard_controls" (such as movement) that are always available.
Anyway, I guess that's some info about how the code works...
Note that the current Controller interface assumes there is only one fire button. An idea I had a long time ago was to have a "two fire button" system. The first button would be for "melee attack" (so swing your sword, axe or hammer) and the second would be "missile attack" (so either throw an axe, shoot a crossbow, or throw daggers depending on what the player has available). Maybe now is the time to look at implementing that...
#69
Knights Discussion / Re: Linux issues
Last post by Stephen - August 13, 2017, 02:09:11 PMThat is indeed interesting. I'm not sure why the old version crashes -- maybe your boost library was built using the newer g++ and that caused an incompatibility somehow?
Oh well, I'm glad that you got it working at least.
Also, this means that there is no bug on my side, which is a good result :)
Oh well, I'm glad that you got it working at least.
Also, this means that there is no bug on my side, which is a good result :)
#70
Knights Discussion / Re: Dagger hotkey
Last post by d.healey - August 13, 2017, 12:36:24 PMYeah that's fair enough. Well I don't mind having a tinker with it, it's been a long time since I worked in C++ though and never on a largish project like Knights so a few pointers are appreciated.
I can see there are a number of a keyboard controller files in the main folder - I guess this is where I should be looking?
I can see there are a number of a keyboard controller files in the main folder - I guess this is where I should be looking?