Understated Ur-Drakon Celtic Minstrel Posted November 25, 2010 Posted November 25, 2010 Originally Posted By: Ishad Nha While we are at it we could have the boats and horses shown in the town display too. That would be nice, yes. Originally Posted By: Ishad Nha BoA has space in the bas file for horse and boat records, a legacy from BoE. So the information could be recorded there. It could be, but doing so would serve no purpose since the game would not be able to find it (unless of course it is able to find it... have you ever tested that?). Originally Posted By: Ishad Nha The data could be printed out in a form suitable for pasting into a scenario file, as create_boat or create_horse functions. Unacceptable; requiring the user to paste the data into the scenario file is silly when it could just insert it directly. Originally Posted By: Ishad Nha Simplest solution is to have the Editor read the scenario file the way it reads the scenario data file. It can look for create_horse and create_boat calls. Yes; only counting calls that appear in the INIT_STATE (or is it the LOAD_SCEN_STATE? I forget). Originally Posted By: Ishad Nha Moving or deleting boats/horses will require a Reload Scenario Script function like the Reload Scenario Data Script function. Or you could just have Reload Scenario Data also reload the scenario script. Originally Posted By: Ishad Nha This won't handle boats and horses that only appear under certain conditions, like those in Exodus. There's no consistent way to do this anyway. Quote
Well-Actually War Trall Ishad Nha Posted November 26, 2010 Author Posted November 26, 2010 All the boat/horse records in the bas file have official status in the source code, so it should work as far as the Editor is concerned, which is all you need. Editor will be used to alter the scenario script file, hence it does not matter if the game accepts the bas file records or not. (Probably it won't, certainly I have edited the bas file to no effect.) From line 755 of latest Windows version of Global.h: class boat_record_type { public: boat_record_type(); void clear_boat_record_type(); location boat_loc,boat_loc_in_sec,boat_sector; short which_town; Boolean exists,property; } ; in reading the Create_Boat call the Editor variables used to translate the Ascript variables will be: i,short which_town,location boat_loc.x,location boat_loc.y,property Edit: I can get the horse and boat icons to show for large and medium views. Next will be large 3D view. Tokens are something I have no experience of, so the hard part will be getting the Editor to read the create boat and create horse calls. To read them and only them. Quote
Understated Ur-Drakon Celtic Minstrel Posted November 26, 2010 Posted November 26, 2010 I maintain that there's no point in using the boat/horse records in the scenario file unless the game itself can recognize them. Inferring boats and horses from the INIT_STATE of the scenario script is fine though. Quote
Well-Actually War Trall Niemand Posted November 26, 2010 Posted November 26, 2010 Originally Posted By: Celtic minstrel Inferring boats and horses from the INIT_STATE of the scenario script is fine though. Inferring could be reasonable. Maybe. Keep in mind that technically you will have to run the state to find out whether it actually initializes any boats or horses, although we could probably do something more simplistic that would be close enough, since if anyone puts an infinite loop in that state he'll have much bigger problems than confusing the editor. Originally Posted By: Ishad Nha Editor will be used to alter the scenario script file This does not sound like a good idea. I assume that the idea would be to let the designer place boats and horses in the editor, and have the editor modify the script state to add the necessary code. It would mean that the editor would need to not only understand the code, but also be able to make modifications without messing anything up. Originally Posted By: Ishad Nha I can get the horse and boat icons to show for large and medium views. Next will be large 3D view.Tokens are something I have no experience of, so the hard part will be getting the Editor to read the create boat and create horse calls. To read them and only them. I assume you mean that you're just testing out drawing them, not actually parsing a script and depicting the data you've read. Keep in mind that to solve this problem, one technically cannot read only the calls of interest, but must read and understand the entire surrounding area of code. Consider: Code: beginstate START_SCEN_STATE;i = 0;while(i<6){ if(char_ok(i)) set_flag(10,i,1); //oops, never increment i}create_boat(0,0,29,15,0);break; Since the loop is infinite, this code never actually creates a boat at all. In general, the only way to discover this is to actually run the code. (The most charming aspect of which is that it may, of course, fail to ever terminate.) This example is a bit pedantic, but here's a more plausible one: Code: beginstate START_SCEN_STATE;//put in a row of boatsi = 0;while(i<3){ create_boat(0,0,16,i,1); i = i + 1;}break; It's not terribly likely that anyone will write something like this, but there's nothing stopping them from doing so, and no simple textual analysis will correctly determine (in general) that this code in fact creates three boats. So, one must use fairly advanced techniques to parse the script code, or restrict the code which the editor can understand to a very simple form or set of forms. Either of these is doable, but a significant amount of work is involved. Also, there is the issue of the (scenario) editor and a text editor likely potentially making concurrent modifications to the script file on disk. There's nothing terribly special about this problem, since anyone can cause it for himself just by using two text editors, but in this case the probability of it coming up is substantial, and there's no reason apparent to the user that it should, so it would need some consideration, I think. Quote
Understated Ur-Drakon Celtic Minstrel Posted November 26, 2010 Posted November 26, 2010 Originally Posted By: Niemand This does not sound like a good idea. I assume that the idea would be to let the designer place boats and horses in the editor, and have the editor modify the script state to add the necessary code. It would mean that the editor would need to not only understand the code, but also be able to make modifications without messing anything up. If the modifications were limited to adding simple calls on the line after the "beginstate INIT_STATE;" line, after removing calls of the same form that appear in the same place, I think it would be safe... though I'm not sure if it'd be sufficient. Originally Posted By: Niemand Also, there is the issue of the (scenario) editor and a text editor likely potentially making concurrent modifications to the script file on disk. There's nothing terribly special about this problem, since anyone can cause it for himself just by using two text editors, but in this case the probability of it coming up is substantial, and there's no reason apparent to the user that it should, so it would need some consideration, I think. TextWrangler, at least, can detect this and either reload from disk or compare to the disk version (allowing you to merge the two). Of course, many people won't be using TextWrangler since it's Mac-only. Quote
Well-Actually War Trall Ishad Nha Posted November 27, 2010 Author Posted November 27, 2010 I am the least talented of the people who do programming for Spiderweb games. Advanced parsing is well beyond my current abilities. Currently I am, of course, hex-editing the boat and horse records into the Bas file. This can be replaced with a BoE-style dialog screen. I have already created a printout for the horse and boat records, they are printed in correct BoA format. Parsing would require the finding of the calls and copying them into memory somewhere. Edit: I have all the graphics able to display properly. I pasted in the BoE dialog screen functions, now I need to get the buttons to work in a BoA editor. This creates a nice IDE atmosphere. If all goes well, the Editor will read the initial values, then it will be able to write directly into the scenario file as the designer works on the scenario. It will take days at least for me to pick up the parsing needed for this. Quote
Easygoing Eyebeast keira Posted November 27, 2010 Posted November 27, 2010 Originally Posted By: Celtic Minstrel TextWrangler, at least, can detect this and either reload from disk or compare to the disk version (allowing you to merge the two). Of course, many people won't be using TextWrangler since it's Mac-only. Notepad++ does the same, and it's Windows. Quote
Well-Actually War Trall Ishad Nha Posted November 28, 2010 Author Posted November 28, 2010 If the parsing does not work out that is annoying but it is no big deal. You will have two files open side by side in the same text editor, all you need to do is copy from one to another. Edit: Horses and boats can now be added to a scenario via the Edit Horses and Edit Boats items on the Scenario Menu. These work just like the BoE functions, (I copied in the BoE code). Relevant horse/boat information is now printed in a form suitable for the BoA scenario file, it is found at the end of the file created by the "Write Scenario Text To Text File" command. While I am at it, I could also create a tool that places horses/boats the way that fields and stains are placed. I will look into this. Customized cursors now reflect the shape of the mirrors. While we are at it we could have multicolor buttons, not just black and gray. Latest version of the Editor is available at: http://www.freewebs.com/ishadnha/VariantBoA3DEditor.zip Edit: Finally managed to create custom button graphics for the buttons that place the mirrors. It took much longer than expected because the code in "void place_right_buttons( /* short mode */ )" actually does nothing. "if(cur_viewing_mode >= 10 && i == 0 && j == 1) // realistic mode palette icon - not working", was a hint to that effect. As for "realistic mode palette icon - not working", no wonder it is not working, this code does nothing. All graphics for the palette buttons are handled up the page in the function void set_up_terrain_buttons() Quote
Well-Actually War Trall Ishad Nha Posted November 30, 2010 Author Posted November 30, 2010 I was looking to replace the palette buttons with something more colorful and representative. I decided to alter their size, this would cause problems with the tiny terrain icons, every time I altered the palette buttons I would need to alter parts of the source code that dealt with the tiny icons. So I split G4915.bmp into two graphics: G4915 handled the palette buttons and G4919 handled the icons you find for secret doors, blocked terrain, damaging floors, navigation points, wandering monster locations, terrain scripts, signs, containers, town entrances and terrain scripts. For whatever reason I could not get the Editor to accept the number 4919 so I had to use 902 instead. I decided to use 16x16 Editor icons but the result did not thrill me. I might try coloring-in the existing palette buttons. http://www.freewebs.com/ishadnha/NewPaletteButtons.png Edit: Commands have been added to the Scenario menu to place horses and boats directly onto the map. Sticky mode is on by default, hit the = key to stop placing horses/boats and resume drawing. Latest version has been uploaded. (It does not use graphic 902.) Now need to alter Clear Space to remove horses and boats. (This has been done.) Horse/boat dialog screens have been altered so that individual records can be deleted. Quote
Well-Actually War Trall Ishad Nha Posted December 7, 2010 Author Posted December 7, 2010 The mysterious "Currently unused" squares in the Edit Town Details dialog turn out to be - Town special on entry - and - Town special on entry if dead -. Holdovers from BoE which are not used by the BoA game. From Blscened.rc: LTEXT "6_0",15,510,220,60,16 LTEXT "6_0",16,510,244,60,16 LTEXT "*Currently unused.",41,299,243,204,17 LTEXT "*Currently unused.",42,300,220,203,15 From Townout.cpp: CDSN(832,15,town.spec_on_entry); CDSN(832,16,town.spec_on_entry_if_dead); Edit: I am now making the readme file more coherent and more useful to anyone who is unfamiliar with the Editor. Select Item and Select Monster screens have been rewritten. (I mean the screens you access on the lower left part of the screen not the menus.) Instead of two columns of 20 monsters/items there is now one column of 25. Further, the monster/item type numbers are now shown to the left. You can jump ahead to a page by choosing the "Start at slot ###:" buttons. Quote
Understated Ur-Drakon Celtic Minstrel Posted December 9, 2010 Posted December 9, 2010 Originally Posted By: Ishad Nha I am the least talented of the people who do programming for Spiderweb games. I beg to differ. Your programming skills may not be as great as some of the other people here, but you seem to have better hacking skills than most of those working on BoE and BoA. Quote
Well-Actually War Trall Ishad Nha Posted December 10, 2010 Author Posted December 10, 2010 Yes, my hacking is getting better all the time. Latest trick, if code is not working, this happens all too often, comment out one line at a time. This shows which lines are working and which are not. Uploaded a new version with an improved readme file. In the file content is grouped according to where the relevant feature appears on the Editor screen. As for extending the mirror placement code to the Mac version: you can look through the Windows code that I uploaded, search through all the files looking for "mirror". The difference between Windows and Mac code is not all that great. Where you see "scen_data.scen_ter_types" replace it with "scen_data.scen_terrains". Five search results won't apply: Click to reveal.. Mac has no Blscened.rc file: C:\Dev-Cpp\Examples\Tortoise Variant\Blscened.rc(1644,71): LTEXT "Do you want to erase all fields (blocked spaces, mirrors, webs, crates, barrels and barriers) in this town?",3,26,20,258,32 These two entries are used only to name fields in the Town Reports: C:\Dev-Cpp\Examples\Tortoise Variant\Bl A Fileio.cpp(113,33): "Unknown","Blocked","Oblique Mirror","Force Barrier","Fire Barrier","Web", C:\Dev-Cpp\Examples\Tortoise Variant\Bl A Fileio.cpp(114,29): "Crate","Barrel","Facing Mirror","Unknown","Unknown","Unknown","Unknown", These two entries are not connected to placement of mirrors: C:\Dev-Cpp\Examples\Tortoise Variant\global.h(288,16): // 36 nw/se mirror C:\Dev-Cpp\Examples\Tortoise Variant\global.h(289,16): // 37 ne/sw mirror Quote
Well-Actually War Trall Ishad Nha Posted December 15, 2010 Author Posted December 15, 2010 Event glitch fixed, see the BoA Bugs topic for details of this. I am now looking at a monster version of Change Terrain Randomly. Firstly, there will be no randomness. Secondly it will be possible to change a lot of the features of monsters: attitude, scripts, some memory cells, timing details and so on. Pressing an LED will select variables to be changed. Then you can enter the old value to found and the new value to replace it with. Multiple variables can be changed at the same time. Quote
Well-Actually War Trall Niemand Posted December 15, 2010 Posted December 15, 2010 Quote: I am now looking at a monster version of Change Terrain Randomly. Firstly, there will be no randomness. Secondly it will be possible to change a lot of the features of monsters: attitude, scripts, some memory cells, timing details and so on. Pressing an LED will select variables to be changed. Then you can enter the old value to found and the new value to replace it with. Multiple variables can be changed at the same time. Why? Is there any demand for this rather complicated feature? Quote
Well-Actually War Trall Ishad Nha Posted December 16, 2010 Author Posted December 16, 2010 It is a quite simple feature to use in practice. Just click on an LED, enter the find value and enter the replacement value. Rather complicated it is not really. It is about five lines of code per variable, plus a couple of breaks and a }, that includes the error checking lines too. I am not too sure there will be much use for it myself, but I don't know. Edit Here is the code for the first variable, creature type: if (cd_get_led(843,2) == 1) { if (cre(CDGN(843,42),-1,255,"Find value error: Creature Type. |Town creatures must have a type number between 0 and 255 inclusive. | (-1 means no monster).","",843) == TRUE) break; if (cre(CDGN(843,62),-1,255,"Replace value error: Creature Type. |Town creatures must have a type number between 0 and 255 inclusive. |(-1 means no monster).","",843) == TRUE) break; if (town.creatures.number == CDGN(843,42)) town.creatures.number = CDGN(843,62); } Quote
Well-Actually War Trall Niemand Posted December 16, 2010 Posted December 16, 2010 I was figuring it would be complicated based on your statement that "Multiple variables can be changed at the same time." This would require a much more complex user interface (and code to handle that interface) than just picking one variable to find-and-replace on at a time. Quote
Well-Actually War Trall Ishad Nha Posted December 16, 2010 Author Posted December 16, 2010 It can alter multiple variables, members of the class creature_start_type, at the same time. I just used it to alter type, facing and attitude for various monsters, this was done in one go. What it can't do is alter more than one value of the same variable. Thus you can't change more than one creature type at a time. Quote
Well-Actually War Trall Ishad Nha Posted December 17, 2010 Author Posted December 17, 2010 I have been able to make the Choose town button work on the Load New Town dialog. It is meant to display a list of the towns in the scenario. Solution involved adding a Case 7 to the get_a_number_event_filter. Ditto the Edit Town Entrance dialog. Now I am trying to make the latter dialog display the name of the chosen town. That is done, just make the Choose function show the number and the name. Quote
Well-Actually War Trall Niemand Posted December 17, 2010 Posted December 17, 2010 This sounds similar to a change I made to the Mac version, although as I recall my changes were to choose_text_res and get_str. We should probably take a look at each others' work so that the two versions are consistent. Quote
Well-Actually War Trall Ishad Nha Posted December 18, 2010 Author Posted December 18, 2010 A bit of standardization won't hurt, I downloaded the Mac source code so I can see how you have done it. I have altered the Change Terrain Randomly function to display the names of floor and terrain in the main screen, dialog 857. I might customize the text so that it says Floor not Terrain when in drawing floors mode. I altered Create Town Entrance so that there is a Delete button to handle deleting of town entrances, there is also a Cancel button that simply closes the screen in the usual way. Quote
Well-Actually War Trall Ishad Nha Posted December 20, 2010 Author Posted December 20, 2010 "there is also a Cancel button that simply closes the screen in the usual way." This did not work out, it deleted the town if you pressed the Cancel inside the select town screen. I have now extended the Choose town function to variable town entry. Each Town number can be entered via the relevant white input box or by the dialog screen created by the Choose button. If entering by the white box, the display of the town name is not updated to reflect the new number. Hence I introduced a Name button that shows the correct town name for that number. Next up, I am adding a selection screen to the Load Outdoor Section function. Edit: I added terrain type and item names to the Item Placement screen. In the Edit Terrain script dialog I have added screens that show the names of all terrain scripts in the current town. You can select a name from this to add to your current terrain script. Ditto for character scripts in the Edit Creature dialog. Quote
Well-Actually War Trall Ishad Nha Posted December 23, 2010 Author Posted December 23, 2010 Item Placement in town, the odds are not used in the actual placing. You set them and they are ignored. The code is below: Click to reveal.. void place_items_in_town() { location l; short i,j,k,x; Boolean place_failed = FALSE; for (i=town.in_town_rect.left; i < town.in_town_rect.right;i++){ for (j = town.in_town_rect.top; j < town.in_town_rect.bottom;j++) { l.x = i; l.y = j; for (k = 0; k < 10; k++){ if (t_d.terrain[j] == scenario.storage_shortcuts[k].ter_type) { for (x = 0; x < 10; x++){ if (create_new_item(scenario.storage_shortcuts[k].item_num[x],l,(Boolean)scenario.storage_shortcuts[k].property,NULL) == FALSE) place_failed = TRUE; } } } } } if (place_failed == TRUE) give_error("Not all of the random items could be placed. The preset item per town limit of 144 was reached.","",0); draw_terrain(); } typedef struct { short ter_type,item_num[10],item_odds[10],property; } item_storage_shortcut_type; Quote
Well-Actually War Trall Niemand Posted December 23, 2010 Posted December 23, 2010 Yeah, that's screwed up. The Mac version of that same function looks like this: Click to reveal.. Code: void place_items_in_town(){ location l; short i,j,k,x; Boolean place_failed = FALSE; for (i=town.in_town_rect.left; i < town.in_town_rect.right;i++){ for (j = town.in_town_rect.top; j < town.in_town_rect.bottom;j++) { l.x = i; l.y = j; for (k = 0; k < 10; k++){ if (t_d.terrain[i][j] == scenario.storage_shortcuts[k].ter_type) { for (x = 0; x < 10; x++){ if(get_ran(1,1,100)<=scenario.storage_shortcuts[k].item_odds[x]){ if (create_new_item(scenario.storage_shortcuts[k].item_num[x],l,scenario.storage_shortcuts[k].property,NULL) == FALSE) place_failed = TRUE; } } } } } } if (place_failed == TRUE) give_error("Not all of the random items could be placed. The preset item per town limit of 144 was reached.","",0); draw_terrain();} I assume that this is closer to how it ought to be, since it at least uses a probability. Quote
Well-Actually War Trall Ishad Nha Posted December 23, 2010 Author Posted December 23, 2010 Original Windows Editor had no mention of the odds so the error started there. I forgot who said that the placement was not working. I have uploaded a new version of the Editor that should have this feature working. Edit, it was Lazarus who pointed out that placement was not random, halfway down on the last page of this link: A new remake Quote
Well-Actually War Trall Ishad Nha Posted December 31, 2010 Author Posted December 31, 2010 New version of the Editor uploaded. Alter Many Monsters function works, except that it can't locate character scripts for the Find what feature. Original dialog functions are idiosyncratic. I might start learning about the usual controls for dialog boxes. Edit: Using mainstream code for dialog windows will enable you to use any mainstream programs for creating those windows. I am looking for a program that will let you design a dialog screen in a MS Paint - like interface. Then it will print out the source code for that screen. I am spending a fair bit of time in MS Paint with screen captures of dialog screens, moving bits around the screen to see what looks best. Also I can see how big text boxes must be to incorporate the bits of dialog that I am writing. Quote
Easygoing Eyebeast keira Posted December 31, 2010 Posted December 31, 2010 I think the Resource Hacker has something That can do that. Quote
Well-Actually War Trall Ishad Nha Posted December 31, 2010 Author Posted December 31, 2010 I will have to look into that. Resource programs have been very useful for finding Original Nethergate and Avernum 1 terrain graphics. I will also search Sourceforge, this is a pressing need for creating program dialogs with a suitable appearance. Edit: XN Resource Editor PE has that ability it would seem. Quote
Hatchling Cockatrice Quiconque Posted December 31, 2010 Posted December 31, 2010 You won't find anything to "paint" dialog boxes because dialog boxes are not made from images, they are made from parts: the window itself, static text boxes, text entry boxes, icons, etc., all with locations and sizes and their own data. On pre-OS X macs this was all handled via resources, so ResEdit back in the day or ResHack today are the tools you'd want. I'm not actually sure what the standard tools are for dialog boxes in OS X and on Windows, but paint programs won't do it. Quote
Easygoing Eyebeast keira Posted December 31, 2010 Posted December 31, 2010 I think he's talking more of something like a WYSIWYG editor for windows. I also remember seeing a thing for a 'window builder' in some IDE awhile back. I can't remember which one it was and google didn't either. Quote
Understated Ur-Drakon Celtic Minstrel Posted December 31, 2010 Posted December 31, 2010 Windows dialogs are somewhat similar to the old Mac ones, I think, except they're stored in the executable. The newer Mac nib files probably use a similar method to store dialogs. Obviously the formats are not the same, but the general concept of how they work is probably very similar. In the BoE code, the dialogs are stored as decompiled resources, whereas the Mac portion has them as compiled resources. It would likely be possible to take the Windows dialog code and run it through something to convert it to the Mac Rez language, then compile them into Mac resources... though format conversion would also be necessary. Quote
Well-Actually War Trall Ishad Nha Posted January 1, 2011 Author Posted January 1, 2011 What I did was find coordinates in the Paint program, then enter them into the relevant dialog in the rc file. Needed is a program that does this automatically, that produces a printout for your rc file. Windows dialogs are stored in a mercifully uncompiled rc file. Then they are compiled right into the program. XN Resource Editor seems to be good, but I can't find any help file anywhere! Quote
Well-Actually War Trall Ishad Nha Posted January 2, 2011 Author Posted January 2, 2011 Now I am following the ideas found in the Mac code and introducing a wider variety of selected instances. I have included preset fields in this list too. Now they can be moved around at will. Some contain items, this problem will need to be addressed. Everything is now properly mobile. I am retaining the selected item numbers system because I know how to use it. Quote
Well-Actually War Trall Niemand Posted January 2, 2011 Posted January 2, 2011 Quote: Now I am following the ideas found in the Mac code and introducing a wider variety of selected instances. I have included preset fields in this list too. Now they can be moved around at will. Some contain items, this problem will need to be addressed. Everything is now properly mobile. I am retaining the selected item numbers system because I know how to use it. Hm. By 'field', I assume you mean what the editor calls fields (which, as we've discussed before, includes all sorts of things except what the game documentation calls fields). With regard to 'fields' like crates, I'd say that the proper behavior is not to mess with any items that are on the same space except to correct their containedness. It won't be what people most likely want but it avoids sticking in more special cases and makes the behavior consistent with what happens when one erases a terrain which is a container and redraws it somewhere else. (If designers yell at us that this is stupid, we can always just put in the special case code.) It hadn't occurred to me yet to make preset fields selectable, but it doesn't seem like a bad idea. I do think that we ought to use the same code on both platforms for handling selections; I've been meaning to try to start merging those changes into the Windows code but I just haven't been able to get to it. While the old number range system was conceptually simple, it was error-prone and pretty inefficient as well. If you search the Mac source code for SelectionType you'll find just about every place where the new selection system is used. Since none of it touches file I/O or drawing operations directly, it should be possible to copy it almost without modification into the Windows source. I don't want to step on your toes by changing things related to that while you're in the middle of doing it already, but I may be able to start working on the Windows stuff more soon (I know I've said this before. . . ) since I've ow got a full (virtual) Windows installation in which I should be able to run the compiler properly. Quote
Well-Actually War Trall Ishad Nha Posted January 3, 2011 Author Posted January 3, 2011 I personally have never had any problems with the Windows numerical system. I have the code worked out and running, it won't take too log to convert it to the format of the Mac source. Select Town Entrances now has the actual name of the town added to it. By fields I mean preset fields, two of which are containers. To handle barrels and crates that contain items would require a new form of selecting instances, one that allows for the selection of more than one item at a time. In the short term I will make it possible to move around anything, signs, whatever. Long term, it would be handy to be able to select and move around blocks of terrain and floors. This will require a new selection method that allows the selection of a lot of things at once. Quote
Well-Actually War Trall Niemand Posted January 3, 2011 Posted January 3, 2011 Quote: Long term, it would be handy to be able to select and move around blocks of terrain and floors. This will require a new selection method that allows the selection of a lot of things at once. I think that this is not a good idea. There isn't a clear logical way that this ought to work (when you displace a floor, what is left behind at the old position?) and there's nothing you can do with a floor or terrain, unlike other objects which have properties that designers need to manipulate. Quote
Well-Actually War Trall Ishad Nha Posted January 3, 2011 Author Posted January 3, 2011 What is left behind? You could either copy or cut the block of floor/terrain/height. If you copy, the existing objects are all left in place. If you cut then you would have default floor, type 0 terrain and default height. It is something to think about. It would make altering a town much easier. A long overdue help file has been added to the Resources folder of the SVN repository. File shows what the program actually does when the source code is compiled. It includes the original Isaac help file as well as my own recent version. The compiled version of the Editor, on the Freewebs link, has always had the help file. Quote
Easygoing Eyebeast keira Posted January 3, 2011 Posted January 3, 2011 Originally Posted By: Ishad Nha SVN repository. When did we get one of these for the editor, and where is it? Quote
Well-Actually War Trall Ishad Nha Posted January 3, 2011 Author Posted January 3, 2011 It looks like it started in February 2009. This is the Windows version address: http://svn.hallsofchaos.net/3D_BoA_Editor_Win/trunk If you have SVN Tortoise software installed on your PC you can access the repository via right clicking, a much better option than downloading one file at a time from the link above. Edit: Signs can be selected easily enough. Around 65 to 70 characters will fit on a line at the lower left part of the screen. Lines 1,2,3,4 can thus hold the whole text of a sign. Quote
Understated Ur-Drakon Celtic Minstrel Posted January 3, 2011 Posted January 3, 2011 Originally Posted By: Ishad Nha Select Town Entrances now has the actual name of the town added to it. Oh, that sounds nice. Originally Posted By: Ishad Nha By fields I mean preset fields, two of which are containers. To handle barrels and crates that contain items would require a new form of selecting instances, one that allows for the selection of more than one item at a time. Or you could just move the crate/barrel and leave the items behind. Originally Posted By: Niemand Quote: Long term, it would be handy to be able to select and move around blocks of terrain and floors. This will require a new selection method that allows the selection of a lot of things at once. I think that this is not a good idea. There isn't a clear logical way that this ought to work (when you displace a floor, what is left behind at the old position?) and there's nothing you can do with a floor or terrain, unlike other objects which have properties that designers need to manipulate. I think I agree with Niemand, though there is an obvious choice for displacing terrain. You should be able to copy/paste blocks of floors, terrain, and height, but I don't see a need to make them selectable and draggable. It's not a bad thing. It's just kind of pointless, especially since copy/paste for terrain and floors is already available. Originally Posted By: Ishad Nha Signs can be selected easily enough. Around 65 to 70 characters will fit on a line at the lower left part of the screen. Lines 1,2,3,4 can thus hold the whole text of a sign. How does this work? Does it just select the sign assignment so that you can now select a sign and move it onto a terrain that's not a sign? Or does it move the sign terrain along with the sign? Quote
Well-Actually War Trall Ishad Nha Posted January 4, 2011 Author Posted January 4, 2011 "It's just kind of pointless, especially since copy/paste for terrain and floors is already available." Yes, currently you can copy/paste floor or terrain from one square only. My idea would enable you to easily move an entire building around. "Does it just select the sign assignment so that you can now select a sign and move it onto a terrain that's not a sign? Or does it move the sign terrain along with the sign?" Currently, the sign terrain stays where it is, you are only changing "location sign_locs[8]" or "location sign_locs[15]". If you place a sign terrain type on the new location then you have a proper sign. Quote
Well-Actually War Trall Niemand Posted January 4, 2011 Posted January 4, 2011 Quote: Yes, currently you can copy/paste floor or terrain from one square only. What on earth is the point of that? It should b fixed, rather than introducing something else, I say. Quote: "Does it just select the sign assignment so that you can now select a sign and move it onto a terrain that's not a sign? Or does it move the sign terrain along with the sign?" Currently, the sign terrain stays where it is, you are only changing "location sign_locs[8]" or "location sign_locs[15]". If you place a sign terrain type on the new location then you have a proper sign. I'm not sure that allowing signs to be moved is a good idea. I'll have to think a bit about the advantages and disadvantages, though. Quote
Well-Actually War Trall Ishad Nha Posted January 4, 2011 Author Posted January 4, 2011 "What on earth is the point of that? It should b fixed, rather than introducing something else, I say. " It makes it simpler to select terrain, just click on it. No need to locate it in the terrain palette. Displaying things like sign text in the lower left part of the screen means you don't have to access dialog boxes all the time, you can work from there. These two ideas have the common theme of working from the adventure screen not dialog boxes. Quote
Easygoing Eyebeast keira Posted January 4, 2011 Posted January 4, 2011 Originally Posted By: Ishad Nha It makes it simpler to select terrain, just click on it. No need to locate it in the terrain palette. That's what the eyedropper tool is for. Wait, the editor doesn't have one...does it? Quote
Well-Actually War Trall Ishad Nha Posted January 4, 2011 Author Posted January 4, 2011 Both previous versions of the Editor, official Spiderweb 2D and Isaac 3D, did not have this feature. It has been added to the recent Mac and Windows versions. (And while we are at it, both 3D Windows versions use the same number for their palette graphic, G4915. Original 3D version will have the wrong graphics for its buttons, an issue that will need to be addressed. Edit: As for copy and paste terrain, we have the functions already in EdFcns.cpp, they seem to be used for nothing. Look at line 3,180 in the latest version of the source file. They seem to come from the Mac version. I added them to the Edit menu. I hit trouble with ctrl, shft and alt keys, terrain would not paste in towns, floor would not paste outdoors. So I set all the keys to TRUE and the problem went away, copy and paste now works. I will need to add an extra row or column to the toolbar palette. Mac version has added an extra column. Quote
Understated Ur-Drakon Celtic Minstrel Posted January 4, 2011 Posted January 4, 2011 Originally Posted By: Ishad Nha "It's just kind of pointless, especially since copy/paste for terrain and floors is already available." Yes, currently you can copy/paste floor or terrain from one square only. My idea would enable you to easily move an entire building around. ...wasn't there a copy rectangle tool? Maybe it was actually something Niemand added, but I definitely remember two tools on the toolbar, one which lets you select a rectangle to copy and the other which lets you paste it by specifying the top left corner. That's what you should do, rather than making a "selected instance" for them. Originally Posted By: Ishad Nha "Does it just select the sign assignment so that you can now select a sign and move it onto a terrain that's not a sign? Or does it move the sign terrain along with the sign?" Currently, the sign terrain stays where it is, you are only changing "location sign_locs[8]" or "location sign_locs[15]". If you place a sign terrain type on the new location then you have a proper sign. This is probably a bad idea since there is then no way to tell if there is a sign on a space. Perhaps a copy sign function, similar to the copy terrain function, would be a better idea. Allowing signs to be selected seems okay, but I don't think you should allow them to be moved. On another note, you should really take a look at the Mac editor to see how it does things before just adding stuff, and try to emulate it whenever you add something that it already has. If you don't have access to a Mac, then ask for screenshots or descriptions as necessary. Quote
Well-Actually War Trall Niemand Posted January 4, 2011 Posted January 4, 2011 Quote: ...wasn't there a copy rectangle tool? Maybe it was actually something Niemand added, but I definitely remember two tools on the toolbar, one which lets you select a rectangle to copy and the other which lets you paste it by specifying the top left corner. That's what you should do, rather than making a "selected instance" for them. I added those to the Mac version. The only thing that's stopping me from adding them to the Windows editor is the difficulty I've had with trying to rearrange the button palette so that it can be expanded to match the Mac version's. Quote: Allowing signs to be selected seems okay, but I don't think you should allow them to be moved. I agree on this. Quote
Well-Actually War Trall Ishad Nha Posted January 5, 2011 Author Posted January 5, 2011 "...wasn't there a copy rectangle tool?" Not on the Windows version before I added it yesterday. "This is probably a bad idea since there is then no way to tell if there is a sign on a space." Town report files tell you exactly where the signs are, ditto object display mode, in the Windows version. "On another note, you should really take a look at the Mac editor to see how it does things before just adding stuff" I actually started to look through the source code, in a methodical way, for the first time yesterday. I have adjusted the Windows toolbar palette to match the Mac version. The flip side is that there is a gap to the right of the terrain palette. Edit: One approach to the gap is to increase the number of floor/terrain slots from 12 to 15 per line. This entails a 50 pixel increase in the width, no big deal as we are going from 772 to 822. This creates the room for the ninth column in the palette toolbar and leaves room to expand to a tenth column. I was able to do this easily enough. Quote
Well-Actually War Trall Ishad Nha Posted January 6, 2011 Author Posted January 6, 2011 I am rearranging the order of the toolbar/palette buttons. Idea is to increase the rhyme and reason behind the order the buttons occur in. 2D/3D button is now next to the zoom button. Mirrors now go with the other fields. I might have the top two lines devoted to drawing, walls and terrain. Now there will be an extra column in the toolbar. I am trying to standardize the graphics so that the left side tells you whether the button acts only on a single square, requires selection of a rectangle or involves editing. I will include a back-up graphic sheet showing the original button graphics. Quote
Well-Actually War Trall Niemand Posted January 6, 2011 Posted January 6, 2011 I already did almost exactly what you describe in the Mac version; you can have a look at image_resources/town_buttons.png and image_resources/outdoor_buttons.png to see what I did. I'd like the Windows buttons to be arranged as similarly as possible, but one key thing in the Mac editor is that I split apart the object palette drawing space, with its associated scrollbar, from the button drawing space, so that I could get in an extra column on the right side. I haven't been able to make this work in the Windows version, although I can make another attempt today. One other thing that will prevent them from being arranged identically right away is that in the Mac version I've already removed a couple of the old tools which were made redundant by the new selection system. One thing that I did not do is to replace any of the existing button icons. With a few exceptions, I think they are pretty good for getting across what they do, and we'll never be able to cram enough information into those tiny rectangles to fully explain each tool. We should probably get some input from other people on changing the look of the buttons completely, and we'll really need to make it consistent between the two platforms if we want one manual to be able to tell people how to use it. Quote
Understated Ur-Drakon Celtic Minstrel Posted January 6, 2011 Posted January 6, 2011 Originally Posted By: Ishad Nha Town report files tell you exactly where the signs are, ditto object display mode, in the Windows version. Having something visible only in a report file is unacceptable. Object display mode... maybe. Still, I would not recommend having movable signs, though allowing copy-paste on signs is good. Just because you can do something doesn't mean you should. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.