Jump to content
Eternal Lands Official Forums

Wytter

Members
 View Profile  See their activity

  • Content count

    1806

  • Joined

  • Last visited

Posts posted by Wytter

  1. Posted · Report reply

    Greetings,

     

    Compile without -Werror and see if it compiles - the signedness are definately not issues, but GCC4 will show them by default. I do not know how much the EL API has changed during the past 6 months, but perhaps it will compile (doubt it). If it does, it should be usable, but needs some more work.

  7. Posted · Edited by Wytter · Report reply

    No, that was for the elc implementation of the network. If someone comes and wants to just replace the networking part (either with a single-player engine or make it use a different network protocol etc.), that can easily be done by just rewriting the network if the gui only calls high-level network functions, hence all changes that are done in the gui will still be done in his part, as he only replaced the networking. It will lead to a lot less maintaining, and more development.

  8. Posted · Edited by Wytter · Report reply

    Yes, that's what it says Radu :P

     

    The reason why I want i.e. load in a different directory is that we might want to later on create external tools that don't use the renderer but just loads the files. They can still use the code that are in the load directory but don't have to depend on the core renderer. The cal3d actors could also be put in an additional sub-directory of the renderer, since we could have support for several formats in the engine.

     

    As for the configuration, the game-specific configuration options and functions should be in the game's own directory. However the higher level functions for i.e. adding a configuration, parsing the configuration files etc. is a part of the engine.

     

    The functions in gui should call high-level network functions that set the protocol and then use a send_tcp_message(Uint8 type, Uint8 * data, Uint32 data_length), where the lower-level function handles the package structure. This way the lower-level function could for instance pack messages together, choose not to have a length parameter on some functions with fixed lengths (hence saving bandwidth), etc. (Will be a lot easier to maintain like this)

    Only the high level network functions should call the low-level network function. Example (pseudo code):

     

    gui:
struct recipe_struct {
	Uint8 pos;
	Uint16 qty;
} manu_recipe;

int mix_clicked()
{
	mix_items(manu_recipe);
	return 1;
}

high-level network:
int mix_items(recipe_struct * recipe)
{
   char data[MAX_RECIPE*(sizeof(Uint8)+sizeof(Uint16))];
   int i;

   for(i=0;i<MAX_RECIPE;i++){
		 data[i*sizeof(recipe_struct)]=recipe[i].pos;
		 Write_Uint16(&data[i*sizeof(recipe_struct)+sizeof(Uint8)],recipe[i].qty);
   }

   send_tcp_data(MIX, data, sizeof(data));
}

low-level network:
int send_tcp_data(Uint8 type, Uint8 * data, Uint32 size)
{
	 char out_data[MAX_OUT_DATA];
	 Uint16 out_size = size+sizeof(Uint8)+sizeof(Uint16);//type (Uint8) + length (Uint16) + data length (size)

	 out_data[0]=type;
	 Write_Uint16(out_data+1, out_size); 
	 memcpy(out_data, data, size);

	return SDL_send(out_data, out_size);//Yea whatever, I don't recall the name of the func;-)
}

     

    I believe that in the core renderer, all debugging functions should follow an assert-like pattern:

     

    int add_character(actor *act)
{
  if(actor_is_null(act == NULL)) return;
...
}

static __inline__ int actor_is_null(int true)
{
	  if(true){
#ifdef DEBUG
			log_error("Tried to add a NULL actor");
#endif
			return 1;
	  } 
	  return 0;
}

     

    These debugging functions would then be put in a .h, so they can be more easily maintained and not pollute the renderer with tons of #ifdef DEBUG's.

  9. Posted · Edited by Wytter · Report reply

    Defines to be applied (remove the #else):

     

    WIDGETS_FIX

    NETWORK_THREAD

    GLUT

     

    Defines to be removed:

    STRONG_SIT_LOCK

    SERVER_DROP_ALL

    ENCYCLOPEDIA

    ELCONFIG - elconfig is obsolete now

     

    To be replaced by run-time loading of library (if available). If we don't want to distribute the png dll, just try loading it on run-time - if it fails, disable the screenshot ability, otherwise enable it.

    PNG_SCREENSHOT

     

    WINDOWS can be replaced by _WIN32

     

    BUG_FIX_3D_OBJECTS_MIN_MAX - is a bug fix for 3D objects bounding box - there's a bug with the current e3d objects and currently it is necissary. Work has been done onto a new e3d format, and when all files are converted into this, it will be removed.

  11. Posted · Edited by Wytter · Report reply

    Gravito: I have already proven that it is possible to share a lot of the base code in map_editor2, this is just taking it to the next step.

     

    ttl: I think that i.e. the queue should be a part of the core functions. Could be in a tools directory, but not sure how necissary that should be...

    As for init... I follow you, but thing is that I don't want code duplication, and the functions for setting up GL are needed in any of the games based on ELC, while the init functions for each game will be slightly different (loading an ini-file different than el.ini etc.)

     

    Entropy: Yes, I have been thinking about that as well. Simply creating a new module for the core engine containing the core and load directories, and then have a network, init and gui directory in the elc module would work fine, and probably cause less confusion. The code will not really be changed, and especially not in that way; they will become a bit more generic though, such as functions for reading el.ini would have to be called with the name of the el.ini you wish to read (that can be "el.ini", "mapedit.ini" etc.) and in functions for creating the window would get the window name, window icon specified.

     

    I have a week off uni in late january, during that week I can put most of the ideas into place. However, it should not happen at the same time as the update since there may be introduced some new bugs. So we'll have to coordinate that.

  12. Posted · Report reply

    Greetings,

     

    I have given some thought into the modularization of elc that we have talked about before. I think that it would be wise to modularize ELC in order to reduce code duplication between different parts of EL (and even different forks).

    In order to do this I decided to split up elc into 5 main components: core, gui, init, load and network. The code in core and load will easily be shared between different forks/parts of elc, while gui, init and network are implementation dependant.

    By dividing the elc into these different components, we will make sure that all clients/the map editor based on elc benifits from the improvements done to the core renderer and loading engine, hence encouraging more cooperation between the different elc forks.

    • elc
      • core
        • Contains the core renderer
        • Contains the window manager
        • Contains the widgets - the single widgets will be in an additional directory, with one file per widget
        • Contains the core sound engine
        • Contains the timers for updating the scenery (animations etc.)
        • Contains a main thread checking the update queue, containing data from the network thread (or map editor or single-player engine)
        • Contains the functions for initiating OpenGL, creating the windows etc.

        [*]gui

        • Contains the different windows for the client.
        • Contains the HUD
        • Contains the command callbacks (both #command and hotkeys), which will manipulate states in the core or call commands found in network.

        [*]init

        • Initiates the client - calls the functions for loading configuration files etc. All functions for GL initiation are in core
        • Contains the command list for the client
        • Contains the configuration init (add_var()...) for the client

        [*]load

        • Map loading/saving. Contains the different versions of the map formats for each of EL's forks
        • Object loading/(saving - for i.e. particles)
        • Texture loading
        • Configuration/saved data file loading
        • Language file loading
        • Music/sound loading

        [*]network

        • Contains the functions for network interaction: Recieving and pre-processing (before displaying) and sending.
        • The package reciever will run in a seperate thread like in the current thread implementation. The reciever would parse the network data, and then send a pointer to the parsed data to the renderer through a queue. This way we could easily remove the network and replace it with a single-player engine.

      [*]map_editor2

      • init
        • Initiates the map_editor. Calls the functions from elc/core for initiating GL.
        • Contains the command list for the map_editor
        • Contains the configuration init (add_var()...) for the map_editor

        [*]gui

        • Contains the windows used in the map_editor
        • Contains the HUD for the map editor
        • Contains the command callbacks (both #command and hotkeys), which will manipulate states in the core/call functions in load.

      [*]Imaginary single-player EL

      • init
        • Can possibly use most of the functions from elc/init, but also needs to initiate the single-player engine, script loader etc.

        [*]gui

        • Additional GUI files + commands + hotkeys for the single-player game

        [*]engine

        • Works sort of like the network in the client, interacting with the core through a queue structure.
        • Contains support for the scripting language of choice

    Please give me some comments on this structure.

  15. Posted · Report reply

    First of all, I don't think it's wise to compile with experimental features like NEW_FRUSTUM. I'd do a compile using:

     

    -DWINDOWS

    -DELC

    -DLOAD_XML

    -DOPTIONS_I18N

    -DPNG_SCREENSHOT

     

    And possibly -DNEW_ACTOR_ANIMATION, but only if it is working as intended...

  16. Posted · Report reply 

    Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912541991488 (LWP 19468)]
0x00000000004092ee in draw_3d_objects (object_type=5926) at 3d_objects.c:342
342					 cache_use(cache_e3d, objects_list[l]->e3d_data->cache_ptr);
(gdb) backtrace full
#0  0x00000000004092ee in draw_3d_objects (object_type=5926) at 3d_objects.c:342
	start = 100
	stop = 101
	i = 100
	l = 5926
	is_selflit = 1
	is_transparent = 0
	is_ground = 5926
#1  0x000000000040a017 in display_objects () at 3d_objects.c:715
No locals.
#2  0x00000000004339fb in display_game_handler (win=0x15f1b60) at gamewin.c:643
	main_count = 62
	times_FPS_below_3 = 0
	next_fps_time = 8083
	last_count = 60
	fps = {1, 1, 100, 0, 0}
	fps_average = 20.3999996
	shadows_were_disabled = 0
	str = "8}P\001", '\0' <repeats 12 times>, "\b\000\000\000\000\000\000\000\0001\026\uffff\uffff*\000\000\000 \000@\000\000\000\000v\231\022\uffff\uffff*\000\000\000 \000@\000\000\000\000\000 \000@\000\000\000\000\001\002\000\000\000\000\000\000\000\000\001\000\000\000\000\000\001\000\000\000\000\000\000\000I\"\023\uffff\uffff*\000\000\000 \000@\000\000\000\000]\025\ubb2a*\000\000\000 \000@\000\000\000\000`\033_\001", '\0' <repeats 28 times>, "]\025\ubb2a*\000\000\000 \000@\000\000\000\000\uffff\uffff\uffff\uffff\000\000\000\000\001\000\000"
	y_line = 2
	i = 74571040
	any_reflection = 2
	mouse_rate = 74571040
#3  0x0000000000429d5a in draw_window (win=0x15f1b60) at elwindows.c:1032
	ret_val = 1
	W = (widget_list *) 0x0
#4  0x000000000042a14f in display_window (win_id=22821632) at elwindows.c:1182
No locals.
#5  0x0000000000428134 in display_windows (level=1) at elwindows.c:54
	id = -1
	next_id = -9999
	i = 0
#6  0x0000000000424144 in draw_scene () at draw_scene.c:94
No locals.
#7  0x000000000044472b in start_rendering () at main.c:123
	event = {type = 3 '\003', active = {type = 3 '\003', gain = 0 '\0', state = 0 '\0'}, key = {type = 3 '\003', which = 0 '\0', state = 0 '\0',
keysym = {scancode = 62 '>', sym = SDLK_RSHIFT, mod = KMOD_NONE, unicode = 0}}, motion = {type = 3 '\003', which = 0 '\0', state = 0 '\0', x = 62,
y = 0, xrel = 303, yrel = 0}, button = {type = 3 '\003', which = 0 '\0', button = 0 '\0', state = 0 '\0', x = 62, y = 0}, jaxis = {
type = 3 '\003', which = 0 '\0', axis = 0 '\0', value = 62}, jball = {type = 3 '\003', which = 0 '\0', ball = 0 '\0', xrel = 62, yrel = 0},
 jhat = {type = 3 '\003', which = 0 '\0', hat = 0 '\0', value = 0 '\0'}, jbutton = {type = 3 '\003', which = 0 '\0', button = 0 '\0',
state = 0 '\0'}, resize = {type = 3 '\003', w = 62, h = 303}, expose = {type = 3 '\003'}, quit = {type = 3 '\003'}, user = {type = 3 '\003',
code = 62, data1 = 0x12f, data2 = 0x0}, syswm = {type = 3 '\003', msg = 0x12f}}
	done = 0
	music_thread = (SDL_Thread *) 0x18ff570
#8  0x0000000000444953 in main (argc=22821632, argv=0x15c2200) at main.c:229
No locals.

     

    Build options:

     

    OPTIONS=-DLINUX -DELC -DPNG_SCREENSHOT -DX86_64 -DNEW_FRUSTUM -DBUG_FIX_3D_OBJECTS_MIN_MAX -DUSE_SHADER #-DUSE_LISPSM

  20. Posted · Edited by Wytter · Report reply

    As for levels: Perhaps you'd only be able to identify the potions you've made on a larger potion level... Sure you can mix it, but you don't know if you've succeeded (The potion would be "unknown", and possibly ruined because of the lower level). Identifying the potion could also only be done after reading books on i.e. chemistry.

     

    And yes, of course it'd include explosive substances, and possibly poisonous. The poisonous substances could actually be used to poison ranged weapons, but that's for another time and place... Just hope the poisonous substance is not creating a steam that you inhale...

  22. Posted · Report reply

    Greetings all,

     

    Since I'm currently working my way through the 1st round of chemistry exams, so I've gotten a lot of chem in my head... With the risk of seaming like a chem-geek, I propose a change in Alchemy and Potions to include some laboratory work.

     

    My idea is that you'd have a small laboratory where you'd go mixing different substances using a new interface. This interface would have pots, glasses and you'd be able to access i.e. vials and other chemicals that are in your bank.

    Now you'd have to extract substances from different plants, dirt and liquids to use for your potions. For instance, to create a basic salt (NaCl) you'd heat up water, untill there's only a heated substance left - to do this you'd start a fire, put the water in a pot (this would be the normal method for boiling), and then add a fire essence. Once that's extracted, you could create hydrochloric acid by pouring sulfuric acid on the salt. The different acids and bases would be used for extracting substances from i.e. herbs, which would then be used to create potions. When mixing the ingredients used for creating the different potions, you'd get n (i.e. 15) vials filled from each batch to make up for the longer creation time.

     

    You'd be able to create recipés with max 6 different ingredients, and only some of the recipés would work - if you put in an item before something else, it might ruin the potion, or make it stronger. If you try making something using a recipé that doesn't exist, the result would be either a failed potion, or you could get lucky and get a very strong/rare potion...

     

    Was just a random idea, but think it could be a hell of a lot more fun (and challenging) than clicking "Mix".

  24. Posted · Edited by Wytter · Report reply

    Just chill people, things will work out alright in the end. I know you're thinking more delays, but actually we're planning a change of the manu system to have similiar delays as in the old days; this is only a part of our plan for overall improving the game and balancing the different skills.

    Currently manufacturing, alch, crafting, etc. have a huge disadvantage over fighters since there are extreme delays - this along with addition of many new items etc. will overall create a LOT better and more balanced game.

×