EGOBOO -- Another editor
Moderator: Developers
Re: EGOBOO -- Another editor
Every object has one "Enchant.txt" that it can apply enchants, "buffs" with, via script functions like EnchantSelf or EnchantTarget.
The effects of many potions use enchants, like the potion of speed. Poison is also done via enchants, the damage over time and the green color shift are done through there. Spells use it too, like Enchant Weapon. I think Polymorph [Lumpkin] uses it too.
Enchants don't carry on from module to module in 2.9.0 (they never did), so even enchants with permanent durations get wiped when the player leaves the module - that is the reason why enchant weapon and enchant armor scrolls only last for the duration of the module they're used in.
Some character passive abilities also use enchant.txt (Adventurer gets +4 to all stats at a certain level), but they get refreshed constantly in the player character's script so that they appear to carry over between modules.
Last time I checked every object could only have 1 enchant.txt.
The effects of many potions use enchants, like the potion of speed. Poison is also done via enchants, the damage over time and the green color shift are done through there. Spells use it too, like Enchant Weapon. I think Polymorph [Lumpkin] uses it too.
Enchants don't carry on from module to module in 2.9.0 (they never did), so even enchants with permanent durations get wiped when the player leaves the module - that is the reason why enchant weapon and enchant armor scrolls only last for the duration of the module they're used in.
Some character passive abilities also use enchant.txt (Adventurer gets +4 to all stats at a certain level), but they get refreshed constantly in the player character's script so that they appear to carry over between modules.
Last time I checked every object could only have 1 enchant.txt.
- penguinflyer5234
- Sheep (Developer)
- Posts: 3025
- Joined: Wed Jul 23, 2008 1:39 am
- Location: Best Southwest
Re: EGOBOO -- Another editor
Every object gets 1 enchant.txt, but they can have "unlimited" enchantments in game*
*where "unlimited" is 200 total for all characters, as of 2.9.0
*where "unlimited" is 200 total for all characters, as of 2.9.0
...
- Zefz
- Squirrel Knight (Administrator)
- Posts: 3820
- Joined: Wed Jul 23, 2008 1:27 am
- Location: Norway
- Contact:
Re: EGOBOO -- Another editor
The old enchant system was quite messy and limited. Each object was only allowed 1 enchant file and they did not last between modules (poison for example). Each update frame the game looped through all 200 enchantments and checked if each was active and applied any effects (and see if any enchantment should be removed).
I remember there were a few bugs where enchants were not properly removed (either removed and not flagged as freed or never removed until the module ended)
I remember there were a few bugs where enchants were not properly removed (either removed and not flagged as freed or never removed until the module ended)
- bitnapper
- Tome Mimic (Module Baker)
- Posts: 135
- Joined: Fri Jan 30, 2009 3:33 pm
- Location: Somewhere near the alps
- Contact:
Re: EGOBOO -- Another editor
Planned implementation:
Each character can be affected by different spells (enchants) at the same time, which have a 'time to live' in ticks or seconds. This is solved by an array of 'clocks' for every character.
You can take a look at the solution ads I add the stub for the 'spells'. Because this structures are 'static', anything can be removed by simply zeroing out the array buffers. There is no need to check for allocated memory. The only dynamic allocated merory will be that for the MD2-Models and possibly the map in later state.
And the OpenGL-Objects, of course
IMHO it's much easier to handle if the main game structures are treated as some kind of database.
The second 'simplification' is to hand over the objects numbers instead of pointers.
I prefer working with static arrays instead of dynamic linked lists, because it makes the code-base easier to maintain.
May be something of a 'deformation professionelle', because I code user interfaces and work with databases for a living
I must confess: The most ideas I have are shamlessly stolen from 'Eye of Beholder I' Which I have 'reverse engineered' for personal use about twelve years ago.
BTW:
I'm working on the particle code for the editor. A lot of work to reproduce... So I decided to create a small standalone programm called 'Particle Kitchen' where I can load particle-files and then test ttheir behaviour. The code for the display of the particles lacks at the moment (Just bounding boxes available) .
Each character can be affected by different spells (enchants) at the same time, which have a 'time to live' in ticks or seconds. This is solved by an array of 'clocks' for every character.
You can take a look at the solution ads I add the stub for the 'spells'. Because this structures are 'static', anything can be removed by simply zeroing out the array buffers. There is no need to check for allocated memory. The only dynamic allocated merory will be that for the MD2-Models and possibly the map in later state.
And the OpenGL-Objects, of course
IMHO it's much easier to handle if the main game structures are treated as some kind of database.
The second 'simplification' is to hand over the objects numbers instead of pointers.
I prefer working with static arrays instead of dynamic linked lists, because it makes the code-base easier to maintain.
May be something of a 'deformation professionelle', because I code user interfaces and work with databases for a living
I must confess: The most ideas I have are shamlessly stolen from 'Eye of Beholder I' Which I have 'reverse engineered' for personal use about twelve years ago.
BTW:
I'm working on the particle code for the editor. A lot of work to reproduce... So I decided to create a small standalone programm called 'Particle Kitchen' where I can load particle-files and then test ttheir behaviour. The code for the display of the particles lacks at the moment (Just bounding boxes available) .
Two beer or not two beer... rather a malt whisky
- bitnapper
- Tome Mimic (Module Baker)
- Posts: 135
- Joined: Fri Jan 30, 2009 3:33 pm
- Location: Somewhere near the alps
- Contact:
Re: EGOBOO -- Another editor
@zefz: It's some mistery to me how the torch particle knows that it has to go up in the Z-Direction, having no Z-Velocity value at all Gravity, Physics and general behavior are mixed up *HRRMPF*
I try to get it using the torch particles...
Progress bar : XXX_______ 15%
I try to get it using the torch particles...
Progress bar : XXX_______ 15%
Two beer or not two beer... rather a malt whisky
- Zefz
- Squirrel Knight (Administrator)
- Posts: 3820
- Joined: Wed Jul 23, 2008 1:27 am
- Location: Norway
- Contact:
Re: EGOBOO -- Another editor
It doesn't move upwards. There is a single attached Flame particle that continuously spawns new Smoke and Flame Trail particles (each which die again within a second or so).
They grow (increase in size) giving the illusion they are moving upwards.
They grow (increase in size) giving the illusion they are moving upwards.
- bitnapper
- Tome Mimic (Module Baker)
- Posts: 135
- Joined: Fri Jan 30, 2009 3:33 pm
- Location: Somewhere near the alps
- Contact:
Re: EGOBOO -- Another editor
Thanks for the info. So it's just an animation attached to the torch, as I understand it. I'm working on a standalone 'Particle Kitchen' to test the behaviour without nneding to start the game. Hope I get it done in reasonable period.Zefz wrote:It doesn't move upwards. There is a single attached Flame particle that continuously spawns new Smoke and Flame Trail particles (each which die again within a second or so).
They grow (increase in size) giving the illusion they are moving upwards.
As I code I work on a small doc how this strange values in the 'part..txt' files are translated to in game values...
Two beer or not two beer... rather a malt whisky
- Zefz
- Squirrel Knight (Administrator)
- Posts: 3820
- Joined: Wed Jul 23, 2008 1:27 am
- Location: Norway
- Contact:
Re: EGOBOO -- Another editor
Yes, particle effects are rather unintuitive.
- bitnapper
- Tome Mimic (Module Baker)
- Posts: 135
- Joined: Fri Jan 30, 2009 3:33 pm
- Location: Somewhere near the alps
- Contact:
Re: EGOBOO -- Another editor
It's a mix up between animated billboards and 'real' particle effects. The animated billboards don't care about physics, that's why some physics code interferes with the display of the torch, I think.Zefz wrote:Yes, particle effects are rather unintuitive.
I added the code for the 'Particle Kitchen' if somebody is interested to use it for testing the particle effects. It looks for the 'part%d.txt' files in the data directory as well as for the particle texture. It uses bitmaps, thus there is no need to load the 'SDL_image' library. It only needs SDL and OpenGL. Billboard display works, but the texture isn't attached yet.
The editor has now the dialog for the characters extended by the display of the items in inventory. And the bounding boxes for the spawned objects take the Z-Value of the tiles into account.
Next I plan to create a little Character-Tool for tests of display of characters and the items in their grips. If that works well, then a big step is done toward the 'Play it' function for the editor.
A first playtest function will implement a 'dumb' AI without any script function. Because attaching the script functionality is a good deal of work Same for collision and damage.
Two beer or not two beer... rather a malt whisky
- bitnapper
- Tome Mimic (Module Baker)
- Posts: 135
- Joined: Fri Jan 30, 2009 3:33 pm
- Location: Somewhere near the alps
- Contact:
Re: EGOBOO -- Another editor
The particle kitchen now works with texturing and basic animation.
It seems to bee correct that the frame rate is in ticks per second (1000 Ticks/Sec). In the case of the torch this is about 10 Frames/Second.
It seems to bee correct that the frame rate is in ticks per second (1000 Ticks/Sec). In the case of the torch this is about 10 Frames/Second.
Two beer or not two beer... rather a malt whisky
- bitnapper
- Tome Mimic (Module Baker)
- Posts: 135
- Joined: Fri Jan 30, 2009 3:33 pm
- Location: Somewhere near the alps
- Contact:
Re: EGOBOO -- Another editor
I decided to put the 'game' part in it's own directory and build a 'standalone' part. I'm still reorganizing code. Some more will be up this weekend, I hope
Still working to figure out the behaviour of the particles. Added 'continuous spawning of particles' in the 'Particle kitchen'. Next step will be a 'char tool' for tests of the animation, 'attached' models and handling grips .
@zefz: Whats the meaning of the '#import' Tag in the 'spawn.txt' file ?
Still working to figure out the behaviour of the particles. Added 'continuous spawning of particles' in the 'Particle kitchen'. Next step will be a 'char tool' for tests of the animation, 'attached' models and handling grips .
@zefz: Whats the meaning of the '#import' Tag in the 'spawn.txt' file ?
Two beer or not two beer... rather a malt whisky
- penguinflyer5234
- Sheep (Developer)
- Posts: 3025
- Joined: Wed Jul 23, 2008 1:39 am
- Location: Best Southwest
Re: EGOBOO -- Another editor
? What #import tag? All I see is #dependency
#dependency loads objects into slots for script spawning or what object is loaded for slot 0
spawn.txt:
#dependency Ghuul 34
a script.txt:
tmpargument = 34 // it's a ghuul
SpawnCharacter // spawns a ghuul
#dependency loads objects into slots for script spawning or what object is loaded for slot 0
spawn.txt:
#dependency Ghuul 34
a script.txt:
tmpargument = 34 // it's a ghuul
SpawnCharacter // spawns a ghuul
...
- bitnapper
- Tome Mimic (Module Baker)
- Posts: 135
- Joined: Fri Jan 30, 2009 3:33 pm
- Location: Somewhere near the alps
- Contact:
Re: EGOBOO -- Another editor
So it would be better with script like SpawnCharacter("ghuul")penguinflyer5234 wrote:? What #import tag? All I see is #dependency
#dependency loads objects into slots for script spawning or what object is loaded for slot 0
spawn.txt:
#dependency Ghuul 34
a script.txt:
tmpargument = 34 // it's a ghuul
SpawnCharacter // spawns a ghuul
But I got it: it's needed for the Starter-Modules...
Thanks.
Two beer or not two beer... rather a malt whisky
- Zefz
- Squirrel Knight (Administrator)
- Posts: 3820
- Joined: Wed Jul 23, 2008 1:27 am
- Location: Norway
- Contact:
Re: EGOBOO -- Another editor
Yep. That's why I was talking about storing object with reference name instead of index number.bitnapper wrote: So it would be better with script like SpawnCharacter("ghuul")
- bitnapper
- Tome Mimic (Module Baker)
- Posts: 135
- Joined: Fri Jan 30, 2009 3:33 pm
- Location: Somewhere near the alps
- Contact:
Re: EGOBOO -- Another editor
I load the objects by name, not by slot. The first 4 Slots are reserverd for laoding player characters. And the next one is needed for the book. Because the book has to be loaded always, if I got it right.Zefz wrote:Yep. That's why I was talking about storing object with reference name instead of index number.bitnapper wrote: So it would be better with script like SpawnCharacter("ghuul")
As I gonna add the script, I'll add the possibility to load objects by name (isn't that implemented yet ?). But I have to support it anyway for a possible transition period.
I still have no idea how I check best that only valid objects are chosen for the spawn list. And how to create 'local' objects.
And I was in bad shape the last few days, that's why there is not much of progress in the code for the editor and the 'gaming' part
Two beer or not two beer... rather a malt whisky