Jump to content

Feature Suggestions, Bug Reports, and so on


Celtic Minstrel

Recommended Posts

  • 2 months later...

I think the if/then node already exists, though it's not filed as an if/then mode; it would be called something like "combat block". A node to take the party into or out of combat mode... I dunno. It's a possibility I guess, but I don't think I much like it.

Link to comment
Share on other sites

The combat block only prevents you from entering a space. I'm thinking something like "if party is in combat, call this special, else call this special."

 

Also, there's a big gob of nodes (end scenario being one) that don't work in combat mode.

 

Quick question: What is the compatiblity of these new nodes? Will older BoEs just skip these nodes, or does it die in some ungraceful way? (this prompts the idea of having a 'compatiblity dialog' in the editor, which would function similarly to the old Starcraft map editor when one tried to save. Oooooohhh, and an if/then node to check the player's version of Blades, so you can have features for new Blades releases but still gracefully degrade to older CBoE versions.)

Link to comment
Share on other sites

Originally Posted By: Sylae Corell
The combat block only prevents you from entering a space. I'm thinking something like "if party is in combat, call this special, else call this special."
Huh, you're right. I remembered incorrectly, I guess. There will be a node to check which "mode" the player is in, yes.

Originally Posted By: Sylae Corell
Also, there's a big gob of nodes (end scenario being one) that don't work in combat mode.
This will probably be changed too.

Originally Posted By: Sylae Corell
Quick question: What is the compatiblity of these new nodes? Will older BoEs just skip these nodes, or does it die in some ungraceful way? (this prompts the idea of having a 'compatiblity dialog' in the editor, which would function similarly to the old Starcraft map editor when one tried to save. Oooooohhh, and an if/then node to check the player's version of Blades, so you can have features for new Blades releases but still gracefully degrade to older CBoE versions.)
Older BoE will not be able to run scenarios created by the as-yet-unreleased enhanced Open BoE; it will instead display a dialog about the scenario being in a newer format then it can handle. This is made possible by the fact that BoE is already equipped to handle incremental improvements to the scenario format.

The new format is going to have a very different set of nodes; many existing nodes will be merged, for example, and a large number will be added... if we ever get around to doing it, that is.
Link to comment
Share on other sites

  • 3 weeks later...

Again, I'm not sure if this was mentioned already, but I found a bug with the current release of OBoE. Cockroaches have their ability set to Petrification Touch by default. Now that Petrification Touch has been fixed, call me shocked while I was playing a scenario in the current release of OBoE that one of my characters was turned to stone by a bite from a Cockroach. This doesn't seem right. This should be changed. The correct ability for the Cockroach would most likely be Causes Disease or something like that.

Link to comment
Share on other sites

This is technically a bug in the scenario, not in OBoE itself; however, the import mechanism for loading old-format scenarios could likely be rigged to detect such discrepancies and automatically fix them. Obviously this'd have to be done without erroneously "fixing" basilisks or anything like that; it would need to specifically check the ones that were incorrect in the original bladbase.

Link to comment
Share on other sites

  • 3 weeks later...
Originally Posted By: S M Adventurer
Again, I'm not sure if this was mentioned already, but I found a bug with the current release of OBoE. Cockroaches have their ability set to Petrification Touch by default.

While Celtic Minstrel is perfectly right in that it is a scenario problem (the basic cockroach had the petryfing touch ability in the default bladbase, hence any scenario made with the old, buggy bladbase would inherit oddly overpowered cockroaches. Of course, that was no problem, since Jeff somehow decided that Petrifying and Disease touches had the same effect code-wise), fixing the petrifying touch ability have indeed created some problems with several legacy scenarios.

I've had some time this week-end to fix a compatibility breaking issue with show/hide town nodes that made some scenarios unwinnable (at least "Of Good And Evil" by Alcritas, see http://www.spiderwebforums.com/forum/ubbthreads.php?ubb=showflat&Number=213050).
While i was at it, i've put a check when loading monsters so that, in legacy scenarios the petrifying touch is replaced by disease touch. That should fix the problem, without impacting any legacy scenario.

Originally Posted By: Celtic Minstrel
Obviously this'd have to be done without erroneously "fixing" basilisks or anything like that; it would need to specifically check the ones that were incorrect in the original bladbase.

Don't worry about that, the petrifying touch was, originally, exactly the same as disease touch (basilisks and others petrifying monsters use Petrification Ray), so there's nothing specific to check.

So, i've release a patch that fixes the two problems mentioned above. Also, i've finally added the ability to change the "scenario format" used, in that designers can now change the "prog make version" array of the scenario. Version 1.x.x is legacy and force the compatibility in the game; anything above (2.x.x , etc) makes use of fixed and new features.

As usual, find the patch at : http://code.google.com/p/openexile/downloads/list

Click to reveal.. (Changelog)

Build 27.09.2010

Classic Blades of Exile :
  • Fixed a compatibility breaking issue concerning Show/hide town nodes.
    Such nodes work the same way it were (i.e flawed) in legacy scenarios, fixing problems about towns that should appear but don't.
  • Petrifying touch ability acts again as Disease touch in legacy scenarios, preventing the "vorpal cockroach" syndrom.
Classic Scenario Editor :

Two new working fields in the Scenario Details dialog :
  • Minimum version, which is unused for now (it represents the minimum version of the game that is needed to play the scenario)
  • Program Make Version (not to confuse with Scenario Version), which is the version of the scenario "format" to use :
    • first number is the major version : set to 1 for legacy scenario, hence forcing legacy compatibility.
      Anything higher is "new scenario" format and makes the game use fixed features (see below).
    • the two next numbers are unused for now.
Things affected by using the "new scenario" format ("program make version" of the form 2.x.x) :
  • town difficulty is used (in legacy scenarios, it was set to 0 for all towns, making it useless).
    Be warned, setting a high difficulty for a town can have dramatic effects on the game : doors of difficulty 10 town are next to impossible to picklock and so on...
    List of things affected by town difficulty :
    • monsters spawning rate
    • doors (resp. barriers) lockpicking/bashing/magically unlocking (resp. dispelling) difficulty
    • trap disarming difficulty and damage they do
  • a special node can be called when a town becomes hostile (see the "Town/Advanced Town Details" menu).
    In legacy scenarios, the "Town special to call..." field is ignored (didn't exist).
  • petrifying touch is fully working (in legacy scenarios, petrifying touch was, in fact, disease touch)
  • resurrection balm IS needed for "Raise Dead" and "Resurrect" spells.
    (in legacy scenarios, the resurrection balm wasn't needed and even, if put in the wrong item slot, could prevent the use of these spells!).
  • the Show/hide node is correctly working (in legacy scenario, the field 2a was checked in place of 1b)


Please note that this is mainly a maintenance release, to fix a game breaking bug in legacy scenarios. The "new scenario" format part was something that was floating around, in the code, for some time and not having time to work on BoE anymore, i've put it in so that eventual/casual designers can benefit from the already fixed/done new features.

Chokboyz
Link to comment
Share on other sites

Originally Posted By: Chokboyz
Don't worry about that, the petrifying touch was, originally, exactly the same as disease touch (basilisks and others petrifying monsters use Petrification Ray), so there's nothing specific to check.
You misunderstand my concern, which is that if a designer specifically set a monster to have petrification touch, it should have petrification touch. So, the fix of replacing petrification touch with disease touch should probably be restricted to monsters that can be recognized as being one of the original erroneous monsters from the bladbase.

Originally Posted By: Chokboyz
Also, i've finally added the ability to change the "scenario format" used, in that designers can now change the "prog make version" array of the scenario. Version 1.x.x is legacy and force the compatibility in the game; anything above (2.x.x , etc) makes use of fixed and new features.
Oh, for... *facepalm* Please do not under any circumstances give the designer the ability to directly control the scenario format version. I would support including a "Enable legacy compatibility" checkbox flag which, if set, makes the version 1.x.x and, if unset, sets the version to whichever latest version the editor knows how to read. Allowing the designer to arbitrarily manipulate these flags could potentially defeat the purpose of their existence, which is to check which version of the scenario editor created the scenario.

Originally Posted By: Chokboyz
Fixed a compatibility breaking issue concerning Show/hide town nodes.
Such nodes work the same way it were (i.e flawed) in legacy scenarios, fixing problems about towns that should appear but don't.
So, does it still check the incorrect field in legacy mode?

Originally Posted By: Chokboyz
Two new working fields in the Scenario Details dialog :
  • Minimum version, which is unused for now (it represents the minimum version of the game that is needed to play the scenario)
  • Program Make Version (not to confuse with Scenario Version), which is the version of the scenario "format" to use :
    • first number is the major version : set to 1 for legacy scenario, hence forcing legacy compatibility.
      Anything higher is "new scenario" format and makes the game use fixed features (see below).
    • the two next numbers are unused for now.
Please replace with a simple checkbox, as mentioned above. The designer should not have the ability to edit internal fields like this.

Originally Posted By: Chokboyz
(in legacy scenarios, the resurrection balm wasn't needed and even, if put in the wrong item slot, could prevent the use of these spells!).
In legacy mode, did you keep the old behaviour entirely or simply remove any effect of Resurrection Balm on the spells?
Link to comment
Share on other sites

Originally Posted By: Celtic Minstrel
You misunderstand my concern, which is that if a designer specifically set a monster to have petrification touch, it should have petrification touch. So, the fix of replacing petrification touch with disease touch should probably be restricted to monsters that can be recognized as being one of the original erroneous monsters from the bladbase.

Nothing is changed for new scenarios : the petrification touch is there and working.
The check/replacement is only done for legacy scenario (in which, no one willingly used the petrification touch, as far as i know, since it was not working).
By the way, such erroneous abilities have been fixed in the current Bladbase.

Originally Posted By: Celtic Minstrel
Oh, for... *facepalm* Please do not under any circumstances give the designer the ability to directly control the scenario format version. I would support including a "Enable legacy compatibility" checkbox flag which, if set, makes the version 1.x.x and, if unset, sets the version to whichever latest version the editor knows how to read. Allowing the designer to arbitrarily manipulate these flags could potentially defeat the purpose of their existence, which is to check which version of the scenario editor created the scenario.
[...]
Please replace with a simple checkbox, as mentioned above. The designer should not have the ability to edit internal fields like this.

I was just using a feature implemented by (i think) Ishad Nha, in the current scenario editor which allowed to manipulate the "prog make version" directly. It was done as a quick and dirty way to test changes, not meant to last in any way (hence the comment).
I'll, when time permits, replace it with a checkbox, as suggested. Quick to do, so it's done...
I'll release the new patch after making sure that nothing more needs to be done.
It's released : http://code.google.com/p/openexile/downloads/list

Originally Posted By: Celtic Minstrel
So, does it still check the incorrect field in legacy mode?

Yup, as it should.

Originally Posted By: Celtic Minstrel
In legacy mode, did you keep the old behaviour entirely or simply remove any effect of Resurrection Balm on the spells?

No, i've removed the need for resurrection balm entirely for legacy scenarios.
In fact, the check was so bugged, that if you had the resurrection balm in an esoteric item slot (let's say 16), casting the spell was prevented and "Resurrection balm needed" message was shown.

Chokboyz
Link to comment
Share on other sites

Originally Posted By: Chokboyz
Nothing is changed for new scenarios : the petrification touch is there and working.
The check/replacement is only done for legacy scenario (in which, no one willingly used the petrification touch, as far as i know, since it was not working).
It may be true that no-one willingly used petrification touch, but I still think it should be honoured if someone did willingly use it.

Originally Posted By: Chokboyz
By the way, such erroneous abilities have been fixed in the current Bladbase.
Yes, I'm aware of that.

Originally Posted By: Chokboyz
I'll, when time permits, replace it with a checkbox, as suggested. Quick to do, so it's done...
Thanks!

Originally Posted By: Chokboyz
In fact, the check was so bugged, that if you had the resurrection balm in an esoteric item slot (let's say 16), casting the spell was prevented and "Resurrection balm needed" message was shown.
This bug is not retained in legacy mode, then?
Link to comment
Share on other sites

Originally Posted By: Celtic Minstrel
It may be true that no-one willingly used petrification touch, but I still think it should be honoured if someone did willingly use it.

Being common BoE knowledge that petrifying touch was in fact disease touch, i doubt anyone used it willingly.
Nonetheless, doing a routine check, after loading a legacy scenario, that would correct the "vorpal cockroaches" mistake (and the likes), would easily solve the problem.
Then again, someone may have wanted cockroaches with petrifying touch in his scenario (just joking ! wink ).

Originally Posted By: Celtic Minstrel
This bug is not retained in legacy mode, then?

Yes. The legacy behavior of not needing resurrection balm is thus preserved/assured (as far as i know, the glitch was so esoteric that no one ever reported/experienced it).

When finishing to use replace overall_mode constants in the game code some time long, i found something weird in the "equip function".
While not being able to equip armor while in combat is a feature of the game, there's also a check to prevent characters from equipping item_variety 11 in combat...
Item_variety 11 being food, i wonder if it's a leftover from Exile 1/2/3 and if something wasn't supposed to be equippable in combat (as far as i recall, armor was the only forbidden thing in Exile 3...).

Chokboyz
Link to comment
Share on other sites

  • 4 weeks later...
Originally Posted By: Celtic Minstrel
That's odd... I can't think of anything else that wasn't supposed to be equippable in combat though, so I'd say just delete the check.

The same here... So, i've deleted the check.

Some last remarks i forgot to post last time :
  • When monsters are firing missiles, differents amounts of ap are removed :
    1 for heat ray, 2 for good_archer, invisibility (hence not used) and razordisks, and 3 for every others missiles.
    The invibility part is probably a typo for darts (invisibility number is 11, darts is 1).
    Anyone can confirm that (from Exile 3 or other) ?
  • Slimes are hardcoded as immuned to sleep (i.e the monster number is checked... leading to monsters bearing those numbers to be sleep-immuned, regardless of the scenario). That should probably be switched to check the monster type (i.e slime).
    Is there any obvious compatibility breaking doing this ? (scenario where slime type is used, without sleep-immunity in mind)
  • Monsters with "Permanent Martyr's Shield" are immuned to Fire Walls and monsters with "Paralysis Ray" are immuned to Ice Walls. While the former may make sense, i'm not so sure about the second... (normal immunities/resistance are correctly applied.)
  • The monster spell "Heal All" isn't a mass spell as the name may suggest but the most powerful and reliable self-healing spell a monster can cast. I propose we rename it to "Heal All Wounds" or something in that vein.
I've finished a quick review of the main part of the game code and replaced lots of numbers by "human readable" constants (from spells to item abilities to monsters abilities) and didn't found obvious bugs, except the ones mentioned above. Finding informations in the code should now be easier and it should be of easier access (quick modifications, etc).
Moreover, Classic Blades of Exile seems stable enough (i.e no problem or incompatibility detected - if you know of one, say it !) to be left in state.
Except if critical bugs or incompatibilities are reported, the next upload should then be my last.

Chokboyz
Link to comment
Share on other sites

Originally Posted By: Chokboyz
[*]Slimes are hardcoded as immuned to sleep (i.e the monster number is checked... leading to monsters bearing those numbers to be sleep-immuned, regardless of the scenario). That should probably be switched to check the monster type (i.e slime).
Is there any obvious compatibility breaking doing this ? (scenario where slime type is used, without sleep-immunity in mind)


Could this part of the code be version or platform-dependent? This is actually something that we did a lot of testing on back in the day for the BoE Arena, and the conclusion was that slime-type monsters were consistently immune to sleep on some people's copies of BoE (in a way that didn't seem to be dependent on the monster ID number), and not immune on others. Incidentally, the Stone and Undead monster types are also immune to sleep.

Quote:
[*]Monsters with "Permanent Martyr's Shield" are immuned to Fire Walls and monsters with "Paralysis Ray" are immuned to Ice Walls. While the former may make sense, i'm not so sure about the second... (normal immunities/resistance are correctly applied.)


Ha! That's an interesting one, and probably related to a bladbase bug where monsters like Salamanders that are supposed to have fire fields have Permanent Martyr's Shield instead, and monsters like Ice Drakes that are supposed to have ice fields have Paralysis Ray instead. I'm almost certain this can be chalked up to some kind of glitch in the process of converting the E3 engine to Blades. Jeff's intent was probably for all monsters to be immune to fields that they themselves generate.
Link to comment
Share on other sites

Originally Posted By: Lilith
Could this part of the code be version or platform-dependent? This is actually something that we did a lot of testing on back in the day for the BoE Arena, and the conclusion was that slime-type monsters were consistently immune to sleep on some people's copies of BoE (in a way that didn't seem to be dependent on the monster ID number), and not immune on others. Incidentally, the Stone and Undead monster types are also immune to sleep.

Indeed, i've just checked and you're absolutely right : in the mac version the stone, undead and slimes types are immuned to sleep (regardless of the number of the monster), while in the windows version the monster between 138 and 142 (basic slimes) are immuned. "Funnily", stone monsters are not immuned to sleep in the windows version (undeads are)...
I'll correct that in the next version (i assume that after so much testing, no one dared make a scenario using this buggy behavior...).

Originally Posted By: Lilith
Ha! That's an interesting one, and probably related to a bladbase bug where monsters like Salamanders that are supposed to have fire fields have Permanent Martyr's Shield instead, and monsters like Ice Drakes that are supposed to have ice fields have Paralysis Ray instead. I'm almost certain this can be chalked up to some kind of glitch in the process of converting the E3 engine to Blades. Jeff's intent was probably for all monsters to be immune to fields that they themselves generate.

Ah, thanks for making the connection ! I agree with your theory, since it won't be the first time such a thing happens.
After checking the mac code, the bug is also present in the mac version. I'll then replace the wrong ability checks by the "radiate field" ability (compatibility ?). Nothing about the "radiate "shock field" ability though, so i'll probably extend the check for those fields.

Thanks for the feedback !
Chokboyz
Link to comment
Share on other sites

Yeah, this is definitely a platform/version difference. On the Mac code, the routine that puts sleep status on monsters is aborted at the start if:

(which_m->m_d.m_type == 8)

(which_m->m_d.m_type == 10)

(which_m->m_d.m_type == 11)

 

But on the PC code, the same routine checks instead for:

((which_m->number >= 138) && (which_m->number <= 142))

(which_m->m_d.m_type == 8)

 

Given that Jeff doesn't seem to know which version of the Mac code he released, and given that the Mac version went through upgrades both prior to, and after, the PC version was released, it's possible that different versions of either platform's game used the alternate code.

Link to comment
Share on other sites

Yup, checks for Stone, Undead and Slime types for Mac, numbers or Undead type for windows.

 

Originally Posted By: CRISIS on INFINITE SLARTIES
Given that Jeff doesn't seem to know which version of the Mac code he released, and given that the Mac version went through upgrades both prior to, and after, the PC version was released, it's possible that different versions of either platform's game used the alternate code.

Given the number of things not implemented in the Windows code that were in the Mac one, i think we're pretty safe considering the Mac code the most recent one.

 

Thanks,

Chokboyz

Link to comment
Share on other sites

Originally Posted By: Chokboyz
When monsters are firing missiles, differents amounts of ap are removed :
1 for heat ray, 2 for good_archer, invisibility (hence not used) and razordisks, and 3 for every others missiles.
The invibility part is probably a typo for darts (invisibility number is 11, darts is 1).
Anyone can confirm that (from Exile 3 or other) ?
The heat ray is supposed to take less action points, I think. I don't know for sure, but it makes sense that darts is supposed to deduct two action points.


Originally Posted By: Chokboyz
Monsters with "Permanent Martyr's Shield" are immuned to Fire Walls and monsters with "Paralysis Ray" are immuned to Ice Walls. While the former may make sense, i'm not so sure about the second... (normal immunities/resistance are correctly applied.)
Yeah, neither of these make sense. Lilith is probably correct here.

Originally Posted By: Chokboyz
The monster spell "Heal All" isn't a mass spell as the name may suggest but the most powerful and reliable self-healing spell a monster can cast. I propose we rename it to "Heal All Wounds" or something in that vein.
Sure, go ahead and change the name. I like the sound of "Full Heal" myself...

Originally Posted By: Chokboyz
the next upload should then be my last.
So, you don't intend to do any work on the game after that?
Link to comment
Share on other sites

Originally Posted By: Lilith
Technically, Avatar is the most powerful self-healing spell a monster can cast. :v

Indeed wink (put the health to its max)

Originally Posted By: Celtic Minstrel
The heat ray is supposed to take less action points, I think. I don't know for sure, but it makes sense that darts is supposed to deduct two action points.

I've then replaced the invisibility check by throw darts.

Originally Posted By: Celtic Minstrel
Sure, go ahead and change the name. I like the sound of "Full Heal" myself...

I now realise my proposition was also misleading, as the "Heal All" spell restore 50 health when casted (as opposed as the random 9-53 of Major Heal).
"Full Heal" may be ok though, unless we find something better.

Originally Posted By: Celtic Minstrel
Yeah, neither of these make sense. Lilith is probably correct here.

I've replaced the faulty abilities check by a corrected one that checks radiate. Then, monsters that radiates fields are now immuned to the type of field they generate (fire, ice, force, sleep, stink).

Originally Posted By: Celtic Minstrel
So, you don't intend to do any work on the game after that?

Given that my contributions are becoming more and more sporadics, mainly due to a lack of time, i really doubt i'll be able to continue working on the game.
Classic Blades of Exile should be stable/legacy compatible enough, but i'll try to check the board from time to time, to see if i missed something important.

Chokboyz
Link to comment
Share on other sites

  • 2 weeks later...

One last glitch found : the ap counter (at the bottom of the game window) isn't updated when un/equipping items (one ap is consumed each time). I've fixed that, but apparently the turn doesn't finish when the ap counter reachs 0 this way.

This hardly seems a feature and i think we should fix that, provided that no scenario makes use of the ability to un/equip items indefinitely in one turn.

 

I'm nearly done and i'll probably release the update this week-end.

 

Chokboyz

Link to comment
Share on other sites

Originally Posted By: Cryolemon
I suppose it has to be asked, but is that behaviour actually a bug, or did Jeff intend it to be the case?

An excellent question...
I've first thought that, the fact that ap stays to 0 without the turn ending, was a bug (not updating the counter is definitely a glitch... since Exile 3), but i've checked the others Exiles and found it there as well.
Even worse, if you keep on un/equipping items in Exile 1 the ap counter goes negative (without any consequences as far as i know).
I've then absolutely no idea if it was intentional or a half-fixed glitch (given the general released code state, my preference goes to the second though). Maybe someone in the community has an answer to that...

Chokboyz
Link to comment
Share on other sites

It's definitely a bug. The documentation in the Exile games says specifically that changing equipment takes an AP. It mentions a lot of things that take up AP, and it never says "but you can do this an infinite number of times at the end of your turn, and follow it up with any one action free." I think it's quite clear that it was not an intended part of the game system that you can change your equipment 20 times, and then cast a spell.

 

The thing is that without the more creative user-made equipment options and more varied monster-fighting situations found in BoE, there was almost never a reason to change even one piece of equipment in the middle of combat. So it is not surprising that this was not raised as an issue during the Exile Trilogy time.

Link to comment
Share on other sites

Originally Posted By: Celtic Minstrel
I suggest we fix the counter but (at least for now) leave in the fact that equipping/dequipping never ends the turn.

Already done, so it's basically fixed. wink

Originally Posted By: Celtic Minstrel
Also, you should probably add a check to prevent the counter going negative (if ap < 0, just show 0).

Fixed since Exile 2.

So, that ends the list of things i was planning to fix before release. I'll then release the Classic Blades of Exile patch soon.

Chokboyz
Link to comment
Share on other sites

  • 1 month later...

The ability to add item descriptions, similar to 'Realmz' so you can add a little flavor to those special items

 

EDIT: Here's something else

 

Allow for weapons to have other special abilities, not sure how to define it all that well, but for example, let's say for example, that you have a spear called Gungnir, that acts as a pole weapon, now let's say this spear can also have the ability to be thrown like a ranged weapon, except it behaves like a regular weapon, and since it's a special ability you wouldn't have to worry about charges or anything.

Link to comment
Share on other sites

Originally Posted By: TheLostOne
The ability to add item descriptions, similar to 'Realmz' so you can add a little flavor to those special items

EDIT: Here's something else

Allow for weapons to have other special abilities, not sure how to define it all that well, but for example, let's say for example, that you have a spear called Gungnir, that acts as a pole weapon, now let's say this spear can also have the ability to be thrown like a ranged weapon, except it behaves like a regular weapon, and since it's a special ability you wouldn't have to worry about charges or anything.


That's a cool idea, but I'm guessing it's easier said than done.
Link to comment
Share on other sites

I'm pretty sure item descriptions should be doable. They were in Exile III also, if not the earlier ones too, and I was a little disappointed that BoE never included them. I think it was suggested before, or someone (CM or Chokboyz?) mentioned long-term plans to eventually incorporate them. Anyhow, I'll add it to the Google Code tracker, for what that's worth. tongue

 

As for weapons simultaneously projectile and melee, I don't know enough about the code to make guesses about how hard that would be yet. I feel like it would be difficult though.

Link to comment
Share on other sites

Originally Posted By: TheLostOne
The ability to add item descriptions, similar to 'Realmz' so you can add a little flavor to those special items
Doable, and if it wasn't planned before it should have been. The main question is whether to give each item a unique description, or have a set of descriptions separate from the items and assign each item one of the descriptions. That is, a one-to-one mapping from description to item, or a many-to-one mapping?

Originally Posted By: TheLostOne
Allow for weapons to have other special abilities, not sure how to define it all that well, but for example, let's say for example, that you have a spear called Gungnir, that acts as a pole weapon, now let's say this spear can also have the ability to be thrown like a ranged weapon, except it behaves like a regular weapon, and since it's a special ability you wouldn't have to worry about charges or anything.
I have to say that this is not very likely. smirk Giving it a once-per-day spell-like ability might be an option, I suppose.
Link to comment
Share on other sites

Originally Posted By: Celtic Minstrel
The main question is whether to give each item a unique description, or have a set of descriptions separate from the items and assign each item one of the descriptions. That is, a one-to-one mapping from description to item, or a many-to-one mapping?


A mix of the two? Say, put in default descriptions that are automatically assigned based on item types, but allow the user to later freely edit them one by one if s/he so desires.

Something like this:
http://www.radiolantine.com/misc/boepic.jpg
Link to comment
Share on other sites

Originally Posted By: Matanbuchus
Originally Posted By: Celtic Minstrel
The main question is whether to give each item a unique description, or have a set of descriptions separate from the items and assign each item one of the descriptions. That is, a one-to-one mapping from description to item, or a many-to-one mapping?


A mix of the two? Say, put in default descriptions that are automatically assigned based on item types, but allow the user to later freely edit them one by one if s/he so desires.

Something like this:
http://www.radiolantine.com/misc/boepic.jpg


That's a cool idea. Dunno how easy it would be to code though (although presumably CM does).
Link to comment
Share on other sites

Originally Posted By: Matanbuchus
A mix of the two? Say, put in default descriptions that are automatically assigned based on item types, but allow the user to later freely edit them one by one if s/he so desires.
Hm, so kind of like a COW (copy-on-write) approach? A new scenario gets a set of stock descriptions for the designer to choose from, but if the designer edits the description of an item then a new one is automatically created? Though having the checkbox seems like a nice touch. I think you might also want a Select button to choose from pre-existing ones.

...so wait, how is this a mixture between the two? It strikes me as the many-to-one mapping...
Link to comment
Share on other sites

I like the "select button rather than check box" idea. (Or select button in addition to check box.) After all, you might need to reorganize some of the default items a little.

 

For maximum customizability, assuming it wouldn't be too much trouble, we could make the set of stock descriptions editable in each scenario too. So if you wanted to change the basic description of every "shield" type item, you'd just make one edit instead of going through and changing each entry by hand.

Link to comment
Share on other sites

Originally Posted By: Matanbuchus
How come? There'd be the default descriptions, and then the customisation box in the item edit screen for those who want to put a description of their own in place for a specific item.

And a select-button or a drop-down menu for choosing from the default descriptions would seem a good idea, too.
So, a bit different from the many-to-one mapping (where there are a bunch of descriptions and each item uses one of them, but multiple items can use the same description). You're suggesting that we have a stock set of descriptions which are used for any item that lacks a description, but you can also give descriptions on a per-item basis which overrides the default.

There's a small problem with having a default description, though. There's no clear way to assign the default description.
Originally Posted By: Matanbuchus
default descriptions that are automatically assigned based on item types,
This sounds good on the surface, but you might remember that the item types for weapons merely specify whether it is wielded in one hand or two. So do you assign a sword description to one-handed weapons? A generic one-handed weapon description? (But why would you want a generic one-handed weapon description?)

On the other hand, having a dropdown or similar to explicitly choose from a default list would work well enough.

Originally Posted By: icelizarrd
I like the "select button rather than check box" idea. (Or select button in addition to check box.) After all, you might need to reorganize some of the default items a little.
One of the options on the select screen could be "Custom", eliminating the need for a checkbox. I dunno if this is a good idea.

Originally Posted By: icelizarrd
For maximum customizability, assuming it wouldn't be too much trouble, we could make the set of stock descriptions editable in each scenario too. So if you wanted to change the basic description of every "shield" type item, you'd just make one edit instead of going through and changing each entry by hand.
Yeah, this makes sense, and wouldn't be that hard (apart from making a new dialog). There'd need to be some consideration of how many stock descriptions there are and what they're describing, since going solely off of item type is not quite sufficient.
Link to comment
Share on other sites

  • 2 weeks later...

Instead of having the sound of a monster attacking be determined by the Monster type, it should be determined by the attack type. Having important characters swing a sword sounding like a sting (or harm, I dunno which)is a little confusing. Also, I think the attacks should be a little more clarified, something like this:

 

Swings: Edged/Hits

Swings: Pole

Swings: Bashing/Punches

Punches

Claws

Bites

Slimes

Stings

Clubs

Burns

Harms

Stabs

Link to comment
Share on other sites

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...