Jump to content

BoA Editor Remake


Recommended Posts

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:
Originally written by Solomon Strokes:

Say, could you have more keyboard shortcuts for placing and deleting objects (ie, barrels, blood, etc) like we had in BoE?

 

And does your "hill formation" tool work on the same flawed bases that the one from the regular BoA editor is based on?

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.

Link to comment
Share on other sites

  • Replies 168
  • Created
  • Last Reply

Top Posters In This Topic

Quote:
Concerning how, could it be possible to replace the indexes in the tr_type's to pointers.
It's OK. Preferable for display routine because pointers speed up the access to the terrain object than index. Index should be converted to pointer with terrain object array.

Quote:
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,
Yes, we can add index as a member to the terrain object.

Quote:
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.
".terrain[" (236 lines) and "->terrain[" (11 lines)
Humm. fair amount.

Auto hill formation
1) Hill formation procedure
Please refer next link
how to develop a scenario?
written March 01, 2005 04:57 AM by Notus

2) cliff terrain
a) Height difference between given square and surrounding eight square determines whether a cliff terrain is attached to the square or not. If any one of eight squares isn't one step higher than the square, the square doesn't have cliff terrain.
1 2 3
8 X 4
7 6 5

Scan each of eight squares. If it is one step higher than the square, give it a value H, otherwise give it L. Then we'll get the eighth paower of 2 = 256 cases.

B) Type of cliff terrain (including convex or concave) is determined by the pattern of these eight squares.
But in some cases, no terrain is attached. Ex.
L L L
H X H
L L L

We can reduce the case using symmetry. But maybe we use a table which has 256 elements for process speed. This algorithm is same as current method essentially. But we can prevent flaw by listing up all cases. Even if some bug would be found, we can easily specify the element which has bug.
Link to comment
Share on other sites

Quote:
oncerning 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?
I think I can.
On 2D, simply change the square color according to height.
On 3D, replace floor with color tile.
a) Do we need to paint side walls with color on 3D?
B) Do we need to display terrains, items and creatures on colored map mode?
It makes the view too complicated. If the mode switch between normal and map mode is quick enough, simple color map may be preferable.
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Quote:
Originally written by Kelandon:
Would it be possible to summarize the status of the project as of right now?
Well, so far, the remake project has just begun. The first step in this is to port the current editor to the wxWidgets framework. This is currently what we're working on. Unfortunately, since the original code was so dependant on global variables, this will take a little longer than expected.

Specifically the loading of the game's core data and the loading/saving of .BAS files are supported in the unfinished port. This may not seem like much, but these are the core components to the editor (new and old).

I believe Notus has already created a User Interface prototype, and by now, he should be able to start putting the editor's views (3D view, 2D view, Realistic view) in. Then we'll have to put in the tool/graphics palette, and at this point we should have a rudimentary program that allows for editing. It probably won't, however, be any better (if its not worse) than the old editor. If this version is released, it will be a very early alpha release.

This is pretty far off, so I'd rather not do any speculation for the future course of this project.

If you have any more questions, I'd be more than happy to answer.
Link to comment
Share on other sites

Kelandon,

Your expectation encourages us much. But please be patient.

 

We started to code new editor actually just after we released Win 3D Editor a month ago.

We are now coping to rebuild not only the user interface but the basic internal structure of the editor. This process is absolutely needed to make large enhancement to the editor, because 3D editor code doesn't have enough strength as the basement. This process is not exciting work for us and also users, because no new function is realized by it. But we know this effort is inevitable if we want to go far.

I hope we can finish this stage in early April.

 

KernelKnowledge12

Quote:
Notus, could you do a quick check to see if the functions work?

OK. I'll check it.

 

Quote:
It probably won't, however, be any better (if its not worse) than the old editor.
- Split and customizable palette

- Multiple and resizable edit windows for towns and outdoor

- Simplified and comprehensive palette icons

- Kohth's wall tool

 

I think it's better than the original 3D editor in this stage.

Link to comment
Share on other sites

I started thinking and the file i/o code I wrote was a temporary solution at best. Thought up a better way to implement it and I wrote the code. I'll test it tomorrow, and start rewriting some of the algorithms in the old code.

 

Also, I tried compiling my code on a different machine, and got some funky results. Turns out Spirit had a bug in its "intersection.hpp". (It didn't affect my computer since I used code straight from Spirit's CVS repository). If anyone's having trouble compiling the code, they should get this file ("intersection.hpp") from Spirit's CVS and put it in the correct place.

 

EDIT:

 

I came across an incredibly annoying problem that I have encountered time and time again in my efforts to port this code. The differing classes used to represent the terrain classes are used too frequently for a secular design to work, so I've decided to create an ambivalent class to represent all terrain types. It will be, physically, the same as the big_tr_type, but it will also have its own internal variable that tells what size it should act as. For efficiency, the iterators should be used whenever possible.

 

This should solve most, if not all, of my problems.

 

For convenience, here's a quick synopsis:

 

struct _tr_type {

terrain_type_type* terrain[64][64];

floor_type_type* floor[64][64];

unsigned char* height[64][64];

unsigned char* lighting[64][64];

 

size_t _size; // can be any number less than 64. hmm, I might templatize it so the max number can be greater than 64.

};

Link to comment
Share on other sites

  • 2 weeks later...

Its been awhile since I've been able to work on this, but I've finally gotten some time.

 

I completely redesigned the terrain classes. Instead of containing four separate arrays, they contain one multi_array (courtesy of Boost) of tiles. I rewrote the outdoor_record_type and town_record_type to hold the terrains. For the sake of simplicity, both structs use the same type of terrain, even though the outdoor's has no need for lighting.

 

Also, the town_record_type struct holds the terrain class, but does not read/write it unless a special read_terrain/write_terrain function is called.

 

I wrote a better file i/o system, and cleaned up the algorithms. After I test my changes, I'll load it into the CVS.

Link to comment
Share on other sites

Has any work been done on a visual editor for creating dialog? There was a topic on this several months ago.

 

Most RPGs have a heavy dialog component. A tool that would allow one to visually create and see dialog flows, with a back end DB to store them, and an engine to spit out completed code would be of great service not only to BoA, but could also be tweaked for use in other RPGs.

 

Someone could make BIG $$$ here if they did this right.

Link to comment
Share on other sites

I was checking my code, and I came across an odd error that I could not trace at all. After about two days of tedious debugging, I found three bugs in the BoA Editor itself that will cause unpredictable effects if fixed.

 

The errors are primarily in the locs_to_dir function. This is indirectly called by the set_up_lights() function, and so has immediate ramifications on every scenario's lighting. I believe I know the basic algorithm used, so I'll correct these bugs, and see how the lighting changes.

 

The main problem with this bug is, that I don't really know if this was a just a mistake or was intended to be wrong, so I don't know if I should correct it. I guess I'll just experiment with one town in a scenario, and if it looks okay, ask the community which type of lighting to keep.

 

Also, on a side note, I think I've noticed a possibility for very limited lighting effects, but I really haven't thought it through.

 

EDIT: Nope, those weren't bugs, just how BoA displays maps. Either way, there's still something wrong with the algorithm, and I think I've found it.

 

As for lighting effects, there's a definite possibility, but it will be limited to night time.

Link to comment
Share on other sites

  • 1 month later...

Sorry for the lack of updates, but I thought people might be getting tired of them.

 

Anyway, I've been able to get back to work, and for now I seem to be the only developer working on this.

 

I'm currently working on the graphics code, and by the end of the week I should be able to start some runtime checking, as I have finished the overall reorganization of the old code. The current code in the CVS will build into a gui that loads all core data as well as the graphics library and is able to save/load .bas files. I'm hoping to have an alpha version released sometime in early June. After the alpha release, however, development (in terms of new features) may become very slow.

 

Any other questions are welcome.

Link to comment
Share on other sites

The editor is clunky right now, but other than being a bit more convenient, I don't think the new one will be that much easier to use, at least in the forseeable future.

 

I mean, BoA is hard and arduous to design in. No amount of utilities will make it easy, even if they make it easier.

Link to comment
Share on other sites

Quote:
Originally written by JadeWolf:
Will the alpha release be available for download? Because I really want a new, easier way for editing BOA so I can finish my scen.
The alpha release will not be meant for editing, its mainly just a base to build features (new and old) upon. These new features will most likely be added in July, as at that point I'll be done with the SATs and my finals.

Quote:
Originally written by Kelandon:
I mean, BoA is hard and arduous to design in. No amount of utilities will make it easy, even if they make it easier.
In what ways (be very specific)? I may be able to help here.
Link to comment
Share on other sites

I think the most useful sort of utility that we don't have right now and no one seems to be working on is a custom objects script utility.

 

I imagine it having four lists, one each for floors, terrains, creatures, and items. Each list would have the number, name, and graphic of the objects. Blank objects would just have a number.

 

Clicking on the object in the list would pop up a window in which one could edit the object. It would look sort of like the HTML editors already in existence: basically, it has a bunch of fields for every possible call (like cr_hp_bonus for creaturs or te_light_radius for terrains) and a few menus for certain things like cr_special_abil that obviously need lists.

 

However, it would read and write directly to the scenario's custom objects script file instead of requiring cutting and pasting. Also, it would also indicate two things for each field, perhaps with colors or perhaps next to the fields: the default value for the field (so 0 for cr_hp_bonus) and the value imported with the initial "import" call.

 

I'm imagining that if the default value was the dominant one (i.e., no call had affected the value yet), the default value would show up in the field in one color (green, let's say), but if the imported value was dominant (i.e. the creature imported had cr_hp_bonus = 30) then the imported value would show up in the field in a different color (blue, perhaps), and if the user changed that value to something different, then it would show up in a third color (black).

 

It'd be nice if it had a built-in feature to read and modify the default items (i.e. it reads corescendata.txt and corescendata2.txt and knows the trick to modify them in a custom objects script), too, because I do this a lot and I'm sure others do as well.

 

Perhaps this could be one of the add-ons to the remade editor. It's not urgent by any means, and remaking the editor is probably more important, but it'd be good to have eventually.

Link to comment
Share on other sites

I thought about doing something like this eventually, and its definitely, as most neccessary components, save the graphical ones, are already evident in the current remake's code. It'll probably be created as the script editor is created.

 

Concerning scripting, are there any things you find yourself doing over and over? Also how exactly do you use SDFs? Do you reserve certain SDFs for certain things in all your scenarios and does keeping track of these places get annoying?

Link to comment
Share on other sites

SDFs don't give me too much trouble. I organize them into groups by their first coordinate thusly:

 

Town-specific SDFs (usually for one-time messages) get the town number. So in town 5, I use (5,0), (5,1), etc. If I need more than thirty, I add 100, because I'm not likely to make a scen with more than 100 towns, so that town 5 would then also get (105,0), (105,1), and so on.

 

Outdoor section-specific SDFs get 200 + x of section times 10 + y of section. So section (3,4) would get (234,0), (234,1), etc. If the outdoors were large, I might have to modify this system, but I haven't yet.

 

Scenario-wide SDFs (and there are only a few of these) get 250. If the outdoors were large, they'd get 290 or something. Thus in Bahs the major scenario-wide SDFs are (250,0), (250,1), etc.

 

With this sort of organizational system and the notes that I take (which you can see because I leave those files in my scenario downloads), SDFs are not much of a problem for me.

 

EDIT: As far as doing things over and over, the only thing that comes to mind is creating one-shot code. I copy and paste this all the time:

 

Code:
 if (get_flag(1,0) == 0) {     set_flag(1,0,1);     // do something, usually a message_dialog     } 
Link to comment
Share on other sites

Oh! I just had a thought! I finally see how a useful scripting utility could work!

 

It would basically be a text editor with modifications. It could use color-coded text, first of all, different colors for different kinds of calls or for strings or that sort of thing.

 

It would also have a list of calls off to the side that would look sort of like this:

 

void block_entry(short do_blockage)

short get_ran(short num_dice,short min,short max)

short is_combat()

 

They could be dragged into the script so that dragging block_entry would put in the script:

 

block_entry()

 

Clicking a call in the list would bring up the Appendices entry for that call.

 

Additionally, it would have a built-in script-checker, maybe based on Alint, which is really good but just has no GUI to speak of.

 

Wow. With that scripting utility, the custom objects utility, and a redone editor, making scenarios would be vastly easier than it was when BoA first came out.

 

EDIT: I have no idea how C++'s precompiler works, so a brief description may be in order.

Link to comment
Share on other sites

The scripting editor would work like Dev-C++'s gui, though without the constant parsing it does. There won't be a drag and drop interface, but there will be a code completion utility. For example, you'd start writing a call to a function, and underneath it the function's declaration (in a yellow box) is shown, such as:

 

block_en

void block_entry( short do_blockage )

 

This is how it is done in VC++ and Dev-C++.

 

As for C++'s precompiler, here are a few simple examples:

 

if you wrote:

Code:
#define SOME_GUY_DEAD_SDF get_flag(10,1)
everytime you wrote SOME_GUY_DEAD_SDF, the precompiler would replace it with get_flag(10,1).

 

if you wrote:

Code:
#define CHECK_SET_SDF( x, y, action) if (get_flag(x,y) == 0) { \                                            set_flag(x,y,1); \                                          action; \                                     }
, then this,

Code:
CHECK_SET_SDF( 1, 20, (         do_something(...);     ) )
would become this:

 

Code:
if (get_flag(1,20) == 0) {    set_flag(1,20,1);    do_something(...);;}
Also, you can say something like:

 

Code:
#ifndef DOING_THIS_PART do this code#elsedo this code#endif
for version compatibility. For advanced uses of the precompiler, look here.

 

All scripts using the precompiler would have to be run through the precompiler before it could be used in the game.

Link to comment
Share on other sites

  • 3 weeks later...

Its been a while since I've given an update, and soon I won't be able to devote much time to this project, as I have up 'till now, so I thought I'd give one. Due to several odd problems, of which I can't seem to find work arounds, I thought it best to switch from wxWidgets to NGL. This should make things easier, and allow for a better interface. Because of this change, the program's alpha release won't be for quite a while. Also, since I'll only be able to work on the project for a few hours a week, progress will be slow.

 

To show that progress has been made, I put up a screenshot on sourceforge of what the editor looks like currently (using wxWidgets), here .

The screenshot is of a partially working 2D view. The code for drawing the 2D view is fine, and the problems are due to the loading of textures, but NGL should help in this area.

 

Also, if anyone believes they can help and is willing to help, please say so here on these forums (or fora as I believe the correct term was pointed out to be), or email me through sourceforge.

Link to comment
Share on other sites

  • 1 month later...

Well, after working on the GUI aspect of the remake, certain, more baneful parts of BoA's design started to show, and I quickly developed an intense migraine, so I started working on the actual editing part of the, umm, editor. This is essentially going to be (at first) in the form of a command line application that allows for directly editing/browsing a .BAS file. It will also contain a scripting engine to automate editing scenarios. While this probably won't be too much use to most people, it'll be the "shell" component of the remake. I've got the basic design down, and since this is a command line application, it shouldn't take too long to get a compiled version.

 

Also, I've recently revamped the BoALib part of the entire project. It's cleaner and better geared towards C++ rather than C.

 

As for the bug I described awhile earlier, I found a way around it that should be enough, though it may annoy some Windows users.

 

Questions/Remarks/Suggestions are welcome.

Link to comment
Share on other sites

Not too sure how I can answer that. Here's essentially what's left to do before an alpha release:

  • Finish the editing part of the editor (about 45% - 55% done)

    </font><ul type="square">

  • <font size="2" face="Verdana, Arial, Helvetica, sans-serif">Technical Details:
  • Add bas_file "registers"
  • Put in inline "accessors"
  • Create grammar that creates bytecode
  • Create main application loop and release

</font></li>

[*]Change the graphic sheet handling part of the GUI code to accomodate both BoA's style and OpenGL's style

[*]Link the editing part of the remake to the GUI, i.e. add menu items, a text box console, toolbox, etc.</ul><font size="2" face="Verdana, Arial, Helvetica, sans-serif">The good thing about the program I'm working on right now is that it should allow for a quick change from alpha release (of the remake) to beta release, since many editing features can be scripted. For example, it should be possible to turn Khoth's Wall Drawing Tool into a script, and therefore avoid going through the trouble of adding it directly to the code.

As for when this should be completed, I can't say. I hope this helps.

Link to comment
Share on other sites

Quote:
Originally written by KernelKnowledge12:
The good thing about the program I'm working on right now is that it should allow for a quick change from alpha release (of the remake) to beta release, since many editing features can be scripted. For example, it should be possible to turn Khoth's Wall Drawing Tool into a script, and therefore avoid going through the trouble of adding it directly to the code.
Is that scripting accessible to other programmers? And non-programmers? Anyway, that sounds really interesting. It makes me imagine your editor remake as a customizable editor, where the scripts would be the plugins. Of course, I may have understood wrong. smile

What's still left to do until alpha release sounds complicated to a non-programmer like me, but keep up the good work. We're looking forward for the alpha release.
Link to comment
Share on other sites

Quote:
Originally written by Overwhelming:
Is that scripting accessible to other programmers? And non-programmers? Anyway, that sounds really interesting. It makes me imagine your editor remake as a customizable editor, where the scripts would be the plugins.
This is the basic idea, except there will be no way to add menu items, buttons etc. to the actual GUI through scripting. People can write scripts and run them through the editor as if they were running a program through the command line.

A script will essentially be a C source file since C is what Avernum Script is based on. There will be a main function that can take any amount of arguments, which, when the script is invoked, will be treated as command line arguments. People can use every part of C except: pointers, references (everything is passed by reference), structs, and dynamic arrays (with the exception of strings). There is one global variable, the .BAS file. Of the supported primitive types, there will be the following:

bool,
int,
location,
rect,
town,
item,
creature,
field,
terrain_script,
outdoor,
wandering,
boat,
horse,
storage_shortcut,
string,
terrain

Details on these primitives and other elements of scripting will be supplied in the documentation.

EDIT:
Quote:

everything is passed by reference
Nevermind about this. Variables can be passed by reference if specified.
Link to comment
Share on other sites

I wish there was something I could do to help, but I doubt there is. I don't know the first thing about C code, and while I've been meaning to learn, I don't have any books or anything, and I'm guessing that what you're doing is a bit too advanced for a beginner anyway.

 

I'd love to help with any beta testing when the time comes, though, and I can point out some bugs/issues with the current 3D Editor.

Link to comment
Share on other sites

Quote:
Originally written by Kelandon:
I wish there was something I could do to help, but I doubt there is. I don't know the first thing about C code, and while I've been meaning to learn, I don't have any books or anything, and I'm guessing that what you're doing is a bit too advanced for a beginner anyway.
The scripting engine I'm creating right now that will allow for editing a .BAS file through scripting will use C, so if you plan to use this feature you'll have to learn.

Here's a very good tutorial on C/C++ that should be as good as any book:

http://www.cplusplus.com/doc/tutorial/index.html

Also, if you have any questions, I'd be happy to answer.

EDIT:

Oh, please list all the bugs/issues with the current editor that you notice. There's a chance I can fix them all at once.
Link to comment
Share on other sites

  • 4 weeks later...

Somehow I never noticed the last response in this thread. Okay, here goes the bugs/annoyances I have with the current 3D Editor:

 

1. BUG: Realistic mode on the edge of outdoor sections sometimes misbehaves. You can see through walls (and they are shown in cutaway mode), as you can see here: screenshot .

 

Compare this with what you see one step further north: screenshot .

 

2. BUG: Realistic mode on the edge of an outdoor section also sometimes blocks off areas of screen for no particular reason. This is inconsistent, but here's one example: screenshot .

 

Here's the same spot in regular 3D mode: screenshot .

 

3. BUG: The 3D editing screen isn't exactly the same size as the BoA playing screen. Here's one spot in 3D editing mode: screenshot . I've made all the visible terrain cave floor, and everything around it is green grass.

 

Here's the same spot in the game: screenshot . You can see corners of green grass.

 

4. ANNOYANCE: The default terrain script name is "dummy." When you place a terrain script, it should just pop up the dialog box asking for a name (and the box should be blank or "dummy" highlighted, so that you can just start typing the name without having to delete something). In fact, you could leave the default as "dummy" if you could change all the boxes to pop up with highlighted text instead of having to move to the end of the box and delete everything.

 

5. ANNOYANCE: The default state to call when placing a special rectangle is 0 and increments by 1 with each rectangle that is placed, although one will probably not ever place a special rectangle that calls state 0. The starting number should be 10. (I can just type in a "1," but I have no doubt that this has confused some newbies who don't know that they're supposed to start with 10.)

 

6. ANNOYANCE: I'd like to be able to edit the adjacent outdoor section's terrain when it's on the screen. This seems hard to do with the current editor setup, though.

 

7. BUG: The calls te_ed_icon_adjust and fl_ed_icon_adjust don't display in 2D mode in the editor, but they do display in the automap in the game.

 

These are the ones that come to mind immediately. They are all really little things that don't bother me much, but if you can fix any of them, I'd appreciate it (and I'm sure all other BoA designers would, too).

Link to comment
Share on other sites

Hmmm, I didn't think there'd be this many. It would probably better to enter them in the bug tracker at the sourceforge site. It would be easier for me to manage them.

 

I'm pretty close to finishing the scripting engine for editing, but if I can't get it to compile by tomorrow, I'll start working on fixing these bugs.

 

If there are any other bugs/suggestions please say so.

Link to comment
Share on other sites

  • 2 months later...

I haven't worked on this in a few weeks, and I probably won't for a while longer due to a broken laptop, college applications, AP, etc.

 

As for the current status of the effort,

 

- the BoALib CVS module works and should allow for much easier development in creating any tool for editing. It parses scenario data scripts, and can load/save .BAS files, using a few calls. If anyone wants to use it, ask and I can give a few technical details regarding its use.

 

- the current 3D Editor code in the CVS module (NOT the source files in the file releases) uses BoALib, and essentially works just the same as the original 3D editor, without import features. The plan is to alter the API dependent features to use wxWidgets and OpenGL, and then release the resulting program as the official, non-beta 3D Editor.

 

All other questions/comments/suggestions are welcome.

Link to comment
Share on other sites

Quote:
Originally written by Kelandon:
Somehow I never noticed the last response in this thread. Okay, here goes the bugs/annoyances I have with the current 3D Editor:

1. BUG: Realistic mode on the edge of outdoor sections sometimes misbehaves. You can see through walls (and they are shown in cutaway mode), as you can see here: screenshot .

Compare this with what you see one step further north: screenshot .
I experienced this too, but not only in outdoors. Also in towns I experience this. I can't show a screenshot, because I don't have website, but what the editor does, is that it sometimes doesn't draw walls. This giving a blank spot which you can't see through. Its not something majot, but it really can get me irritated if it happens on a really important spot. What you mentioned, kelandon, happens when you have a cliff or walls in outdoors at the border of two outdoor sections. Still it shouldn't happen, but the reason for this, is simply that when you work on one outdoor section, you don't work on the other, meaning that the editor will just draw the other section as if you simply are not working in it. This also means it will draw the walls in the mode of very low, like you showed in the screenshots.

Something I also noticed, is that the editor ussually makes places much darker than they are in the game. Mainly walls are sometimes totally black in the editor, but in the game I can still see textures on the same walls.
Link to comment
Share on other sites

Quote:
Originally written by Thralni, emperor of Riverrod:
I experienced this too, but not only in outdoors. Also in towns I experience this. I can't show a screenshot, because I don't have website, but what the editor does, is that it sometimes doesn't draw walls. This giving a blank spot which you can't see through. Its not something majot, but it really can get me irritated if it happens on a really important spot. What you mentioned, kelandon, happens when you have a cliff or walls in outdoors at the border of two outdoor sections. Still it shouldn't happen, but the reason for this, is simply that when you work on one outdoor section, you don't work on the other, meaning that the editor will just draw the other section as if you simply are not working in it. This also means it will draw the walls in the mode of very low, like you showed in the screenshots.
Finding the causes to these bugs may take a while due to the way the 3D code is written. Unfortunately, it was written that way because the rest of the editor was written that way. Until serious modularization of code, and separation of concepts, so-to-speak, is done, smaller bugs like this will be somewhat hard to trace.

Quote:

Something I also noticed, is that the editor ussually makes places much darker than they are in the game. Mainly walls are sometimes totally black in the editor, but in the game I can still see textures on the same walls.
This doesn't make too much sense. The editor is supposed to show places fully lit. Ah well, something else to look into, I guess.
Link to comment
Share on other sites

  • 1 month later...
  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...