Profile for KernelKnowledge12
| Field | Value |
|---|---|
| Displayed name | KernelKnowledge12 |
| Member number | 4557 |
| Title | Shock Trooper |
| Postcount | 264 |
| Homepage | |
| Registered | Wednesday, June 16 2004 07:00 |
Recent posts
Pages
| Author | Recent posts |
|---|---|
| BoA Editor Remake in Blades of Avernum | |
|
Shock Trooper
Member # 4557
|
written Monday, March 14 2005 13:10
Profile
I finished testing the I/O functions, and I'm fairly sure they work completely. To test them, I used the load_campaign function to load a scenario. I then saved it to a new file, and opened the new file in the editor. The new file worked just as the old one. There was, however an oddity when I tried another test. Instead of loading the file in the old editor, I compared the two files, byte by byte. According to this method, the current town was not saved correctly. This makes no sense as it was loaded fine in the old editor. Notus, could you do a quick check to see if the functions work? Also, I won't be able to do too much coding for a little while. I'll be able to do some, but not a lot. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| Unhandled Exceptions in Blades of Avernum Editor | |
|
Shock Trooper
Member # 4557
|
written Saturday, March 12 2005 15:12
Profile
Yeah I guess I overstressed the detriment to game speed, but the fact that some scripts are only run once every some turns, implies that BoA's scripting engine is generally slow. The editor's code implies that BoA does not go the traditional route of converting scripts to byte code before running them, which slows script execution. Of course, this is all speculation. EDIT: Just read your post, Kelandon. Alint checks one script. BoA simultaneously reads several scripts, relates them to game's actual state, updates the game state, and then actually runs the game. The added checks probably wouldn't do much to game speed, but as a programmer I guess I've been sort of indoctrinated to think in terms of efficiency. [ Saturday, March 12, 2005 15:21: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| Unhandled Exceptions in Blades of Avernum | |
|
Shock Trooper
Member # 4557
|
written Saturday, March 12 2005 15:12
Profile
Yeah I guess I overstressed the detriment to game speed, but the fact that some scripts are only run once every some turns, implies that BoA's scripting engine is generally slow. The editor's code implies that BoA does not go the traditional route of converting scripts to byte code before running them, which slows script execution. Of course, this is all speculation. EDIT: Just read your post, Kelandon. Alint checks one script. BoA simultaneously reads several scripts, relates them to game's actual state, updates the game state, and then actually runs the game. The added checks probably wouldn't do much to game speed, but as a programmer I guess I've been sort of indoctrinated to think in terms of efficiency. [ Saturday, March 12, 2005 15:21: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| Unhandled Exceptions in Blades of Avernum Editor | |
|
Shock Trooper
Member # 4557
|
written Saturday, March 12 2005 14:30
Profile
Come to think of it these errors should not be fixed by Jeff. This would require the game checking every time for a possible error, even if the error isn't there. This might seriously slow the game. We should, however, ask Jeff to create a debug version of the game that does check for things like this. This should take just as long as fixing the App. As for errors, these come to mind: - Over indexing an item/creature/floor/terrain - Using a string that is over 256 chars - Using a string over 30 chars in setting an item's full_name - Using a string over 14 chars in setting a scripts name - Using a string over 20 chars in setting an object's (floor/terrain/creature/item) name These are only possible errors. I have no idea if they actually crash BoA. Also, this is a very small list, compared to all the things that could in theory crash BoA. I'd rather not put them all down until I have a better idea of what is handled in BoA. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| Unhandled Exceptions in Blades of Avernum | |
|
Shock Trooper
Member # 4557
|
written Saturday, March 12 2005 14:30
Profile
Come to think of it these errors should not be fixed by Jeff. This would require the game checking every time for a possible error, even if the error isn't there. This might seriously slow the game. We should, however, ask Jeff to create a debug version of the game that does check for things like this. This should take just as long as fixing the App. As for errors, these come to mind: - Over indexing an item/creature/floor/terrain - Using a string that is over 256 chars - Using a string over 30 chars in setting an item's full_name - Using a string over 14 chars in setting a scripts name - Using a string over 20 chars in setting an object's (floor/terrain/creature/item) name These are only possible errors. I have no idea if they actually crash BoA. Also, this is a very small list, compared to all the things that could in theory crash BoA. I'd rather not put them all down until I have a better idea of what is handled in BoA. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| Unhandled Exceptions in Blades of Avernum Editor | |
|
Shock Trooper
Member # 4557
|
written Saturday, March 12 2005 13:36
Profile
I may be able to help in this matter by looking at the editor's code, but since I'm not a scenario designer I would need to know what BoA does give an error for. For example, if you specify a location that is invalid, like (2000,4000), does it crash BoA or give an error? EDIT: For clarity: by "crash BoA" I meant the program gives an Unhandled Exception, and by "give an error" BoA actually says what the error is. [ Saturday, March 12, 2005 13:44: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| Unhandled Exceptions in Blades of Avernum | |
|
Shock Trooper
Member # 4557
|
written Saturday, March 12 2005 13:36
Profile
I may be able to help in this matter by looking at the editor's code, but since I'm not a scenario designer I would need to know what BoA does give an error for. For example, if you specify a location that is invalid, like (2000,4000), does it crash BoA or give an error? EDIT: For clarity: by "crash BoA" I meant the program gives an Unhandled Exception, and by "give an error" BoA actually says what the error is. [ Saturday, March 12, 2005 13:44: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| BoA Editor Remake in Blades of Avernum Editor | |
|
Shock Trooper
Member # 4557
|
written Thursday, March 10 2005 19:58
Profile
I would be in favor of the simple color map, but we can put options for displaying items/creatures/etc. in the program. Come to think of it, I can't see any use for displaying items/creatures/etc. in this type of view, but then again I'm not a scenario designer. Either way we should just ask the community before adding it. EDIT: Finished applying the change to the terrain classes/outdoor class. I'll start working on the load_campaign function. I should be done pretty soon. EDIT: Finished with the file io functions. I need to check if they work completely. The save_campaign function does not work if the current town has changed its size. This should be changed. [ Sunday, March 13, 2005 12:25: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| BoA Editor Remake in Blades of Avernum | |
|
Shock Trooper
Member # 4557
|
written Thursday, March 10 2005 19:58
Profile
I would be in favor of the simple color map, but we can put options for displaying items/creatures/etc. in the program. Come to think of it, I can't see any use for displaying items/creatures/etc. in this type of view, but then again I'm not a scenario designer. Either way we should just ask the community before adding it. EDIT: Finished applying the change to the terrain classes/outdoor class. I'll start working on the load_campaign function. I should be done pretty soon. EDIT: Finished with the file io functions. I need to check if they work completely. The save_campaign function does not work if the current town has changed its size. This should be changed. [ Sunday, March 13, 2005 12:25: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| Tastes like chicken. in General | |
|
Shock Trooper
Member # 4557
|
written Thursday, March 10 2005 19:25
Profile
Bring Your Own Bread. :P Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| BoA Editor Remake in Blades of Avernum Editor | |
|
Shock Trooper
Member # 4557
|
written Thursday, March 10 2005 19:00
Profile
I'll get started on the change to the terrain objects. Concerning heights, I think I recall your idea of the color map for editing heights. I believe this is a very good idea. Did you ever find out if it was implementable? Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| BoA Editor Remake in Blades of Avernum | |
|
Shock Trooper
Member # 4557
|
written Thursday, March 10 2005 19:00
Profile
I'll get started on the change to the terrain objects. Concerning heights, I think I recall your idea of the color map for editing heights. I believe this is a very good idea. Did you ever find out if it was implementable? Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| BoA Editor Remake in Blades of Avernum Editor | |
|
Shock Trooper
Member # 4557
|
written Thursday, March 10 2005 13:09
Profile
I couldn't create a more generic form of the functions with an algorithm-like representation. They are much too dependent on the global variables, specifically scen_data. This should definitely change, but I don't know when we should change it. Concerning how, could it be possible to replace the indexes in the tr_type's to pointers. For example, instead of declaring it like this: class big_tr_type { ... public: short terrain[48][48]; ... } it would be like this: class big_tr_type { ... terrain_type_type* terrain[48][48]; ... } The file io would have to be changed to convert these pointers to indexes, and the opposite for writing. This is a very simple procedure, but the hard part comes in when copying the rest of the original code. Any code that uses scen_data to index has to be changed to just use the pointer. This shouldn't be hard, but will take a long time. Is this something we should do now? EDIT: quote:Ooops, I waited too long to post. Anyway, keyboard shortcuts should be fairly simple, but this will have to wait some time. At first we will most likely use the "hill formation" tool in the editor, but this will definiately change later on in development. [ Thursday, March 10, 2005 13:13: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| BoA Editor Remake in Blades of Avernum | |
|
Shock Trooper
Member # 4557
|
written Thursday, March 10 2005 13:09
Profile
I couldn't create a more generic form of the functions with an algorithm-like representation. They are much too dependent on the global variables, specifically scen_data. This should definitely change, but I don't know when we should change it. Concerning how, could it be possible to replace the indexes in the tr_type's to pointers. For example, instead of declaring it like this: class big_tr_type { ... public: short terrain[48][48]; ... } it would be like this: class big_tr_type { ... terrain_type_type* terrain[48][48]; ... } The file io would have to be changed to convert these pointers to indexes, and the opposite for writing. This is a very simple procedure, but the hard part comes in when copying the rest of the original code. Any code that uses scen_data to index has to be changed to just use the pointer. This shouldn't be hard, but will take a long time. Is this something we should do now? EDIT: quote:Ooops, I waited too long to post. Anyway, keyboard shortcuts should be fairly simple, but this will have to wait some time. At first we will most likely use the "hill formation" tool in the editor, but this will definiately change later on in development. [ Thursday, March 10, 2005 13:13: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| Tastes like chicken. in General | |
|
Shock Trooper
Member # 4557
|
written Thursday, March 10 2005 12:47
Profile
I'm fairly certain that it's faked. Or at least it is now. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| Article - Rollick in Blades of Avernum Editor | |
|
Shock Trooper
Member # 4557
|
written Thursday, March 10 2005 11:19
Profile
quote:Perhaps a better question would be why people keep arguing with him. It hasn't been very productive. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| Article - Rollick in Blades of Avernum | |
|
Shock Trooper
Member # 4557
|
written Thursday, March 10 2005 11:19
Profile
quote:Perhaps a better question would be why people keep arguing with him. It hasn't been very productive. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| Tastes like chicken. in General | |
|
Shock Trooper
Member # 4557
|
written Thursday, March 10 2005 11:09
Profile
Ask him to breakdance and seduce you. Its very odd. I wonder how much you get paid for that. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| Tastes like chicken. in General | |
|
Shock Trooper
Member # 4557
|
written Wednesday, March 9 2005 11:09
Profile
Mmmmm. Chicken. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| BoA Editor Remake in Blades of Avernum Editor | |
|
Shock Trooper
Member # 4557
|
written Tuesday, March 8 2005 18:29
Profile
I just finished the algorithms neccessary for set_up_lights to function (sorry for the delay). It is loaded into the CVS, but I think I should look it over some. It isn't commented, so I apologize for any confusion. I'll work on the fileio tomorrow, and then write the old_can_travel functions. Just saw the town limit part of your post Notus. I think I forgot that the editor writes those 2 arrays as full length no matter how many towns there are. The BoA application, then, must read it in this way. Thank you for clearing this up. EDIT: Finished with the save_campaign() function. [ Wednesday, March 09, 2005 15:23: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| BoA Editor Remake in Blades of Avernum | |
|
Shock Trooper
Member # 4557
|
written Tuesday, March 8 2005 18:29
Profile
I just finished the algorithms neccessary for set_up_lights to function (sorry for the delay). It is loaded into the CVS, but I think I should look it over some. It isn't commented, so I apologize for any confusion. I'll work on the fileio tomorrow, and then write the old_can_travel functions. Just saw the town limit part of your post Notus. I think I forgot that the editor writes those 2 arrays as full length no matter how many towns there are. The BoA application, then, must read it in this way. Thank you for clearing this up. EDIT: Finished with the save_campaign() function. [ Wednesday, March 09, 2005 15:23: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| BoA Editor Remake in Blades of Avernum Editor | |
|
Shock Trooper
Member # 4557
|
written Saturday, March 5 2005 21:21
Profile
I've started porting a rather long string of functions into the new editor, and I've found it neccessary to remake most of them. To do this, I've created a line class with three iterators (in line.hpp), and made a new direction system (in directional.hpp). The line class' tile_iterator will be used on the old_can_see, etc. functions, which I plan to split into four separate functions. Notus, Isaac (any other developers who are working on this), please take a look at these files, and make sure you don't see anything wrong with them. I believe I'll have these functions done by the end of the weekend: look_block move_block old_can_see_to old_can_see_in old_can_travel_to old_can_travel_in set_up_lights After this, I should be able to finish the file i/o functions pretty fast. EDIT: Nevermind about my direction system; I don't believe I was thinking clearly when I coded it. Also, I think I'll only split the old_can_see function into two different functions. EDIT: FYI, I only tested my tile iterator for forward iteration. It my not work with backward iteration, but I'll test it soon. EDIT: I was looking at the terrain classes (ave_tr_type, big_tr_type, tiny_tr_type) and I thought it would speed things up if instead of holding indexes to a specific floor or terrain, they held the actual pointers to the objects. This way instead of referencing the scen_data object every time a terrain was drawn, the program could just use the terrain object. Notus, would this be a good idea, and if so, should we implement it now or later? [ Sunday, March 06, 2005 12:52: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| BoA Editor Remake in Blades of Avernum | |
|
Shock Trooper
Member # 4557
|
written Saturday, March 5 2005 21:21
Profile
I've started porting a rather long string of functions into the new editor, and I've found it neccessary to remake most of them. To do this, I've created a line class with three iterators (in line.hpp), and made a new direction system (in directional.hpp). The line class' tile_iterator will be used on the old_can_see, etc. functions, which I plan to split into four separate functions. Notus, Isaac (any other developers who are working on this), please take a look at these files, and make sure you don't see anything wrong with them. I believe I'll have these functions done by the end of the weekend: look_block move_block old_can_see_to old_can_see_in old_can_travel_to old_can_travel_in set_up_lights After this, I should be able to finish the file i/o functions pretty fast. EDIT: Nevermind about my direction system; I don't believe I was thinking clearly when I coded it. Also, I think I'll only split the old_can_see function into two different functions. EDIT: FYI, I only tested my tile iterator for forward iteration. It my not work with backward iteration, but I'll test it soon. EDIT: I was looking at the terrain classes (ave_tr_type, big_tr_type, tiny_tr_type) and I thought it would speed things up if instead of holding indexes to a specific floor or terrain, they held the actual pointers to the objects. This way instead of referencing the scen_data object every time a terrain was drawn, the program could just use the terrain object. Notus, would this be a good idea, and if so, should we implement it now or later? [ Sunday, March 06, 2005 12:52: Message edited by: KernelKnowledge12 ] Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| BoA Editor Remake in Blades of Avernum Editor | |
|
Shock Trooper
Member # 4557
|
written Thursday, March 3 2005 17:56
Profile
Not in the Windows version. I guess Jeff wasn't as lazy when he created the Mac version of the editor. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |
| BoA Editor Remake in Blades of Avernum | |
|
Shock Trooper
Member # 4557
|
written Thursday, March 3 2005 17:56
Profile
Not in the Windows version. I guess Jeff wasn't as lazy when he created the Mac version of the editor. Posts: 264 | Registered: Wednesday, June 16 2004 07:00 |