Posts made by Vizzini

Hi Ryan,

Here's the transport code examples I mentioned. They're not mine, I just wrote the Makefile cos there wasn't one.

Cheers,

Scott.

:banghead: transport-code.tar.gz

I like the idea of an animated stone race. I'm fully behind the idea of having more distinct races than the standard human sized biped. A race with 8 arms for example, a centaur like race that can act as a mount for another player, an outsized troll like race that benefits from massive strength but very limited magical or skilled ability. That kinda thing. Nice idea. Vizz.

I'd like to suggest the script for the gatekeeper to the castle in achaeus be modified to mention where to kick off the miniquest for the achaean citizenship papers. Right now there's no overt clue on where to start.

Scott.

Inconceivable!

Hey all, Been a while since I posted any kind of progress update, so I guess I'd better write one. For those who don't know, I have my own company and the end of the financial year is looming (31st March), and I have a large tax bill to meet so I've been working my ass off. The wilds work has suffered as a result so there's not a massive amount to report. * Rewrote the Terrain and Vlinks loading/saving routines to use Syn's value tags method rather than the stock ROM lazy-man's method of using absolute fixed fields. This is much more fault tolerant and makes the area files bigger, but much more readable. It also keeps the wilds files in roughly the same format as the rest of the area file format, which makes me more comfortable (and will save me lots of explaining time when Nib comes to rewrite PGN2ARE). * Spent some time bullet-proofing various parts of the wilds OLC. Again, a lot of testing will still be required but I wanted to head-off some of the dumber and more obvious bugs before beta testing begins in earnest. * Vlinks can be linked/unlinked from the OLC now. I wasn't happy with the way this had been done previously, so I rewrote the linking and unlinking routines so that they are more compartmentalised, so the code can be reused when it comes to putting in script hooks for allowing room/mob/obj scripts to link/unlink vlinks. * At Nib's request I made vlink wilds entrance tiles customisable in the OLC, and also modified the loading/saving code appropriately. I'll try to do more in the coming week. I realise you guys are waiting for this. Cheers, Scott.

This one's kinda directed at Areo specifically, but I guess there may be others with a vested interest.

Is there any possibility of us getting a java-based telnet gateway to the game/testports that would allow SSL connections? I'd like to be able to work on stuff during the day at work, but of course there's a proxy in the way that only allows http/https connections. It's not critical, I just wondered if there was an easy way to do it, and if there were any show-stoppers in our hosting agreement or whatever...

Goes without saying I'd never use any of the plethora of free ones on the net that no doubt grab account information for their owners. (Am I paranoid?)

Scott.

I think Nib's prolly the man to speak to about this. From a coder's perspective, there's an internal function dice() that takes an argument along the lines of dice(d+offset). e.g dice (20d6+10) would give you a min result of 10 + 20d6 = 30, max result 10 + 20d6 = 130. The only problem I see with functions like these is of "striping", where the random factor isn't actually very random, making the randomisation a little "predictable", which is to say that in repeating the same function over and over and recording the results, definite patterns emerge in the data. Linux provides a number of methods of providing much more random data, utilising things like entropy data extracted from the normal operation of the system, none of which are hard to implement. Indeed, there are external entropy packages we could employ for just this purpose. In summary, I don't think it would be hard to give you a method of generating finite and bounded randomness based on defined probablility constraints. In fact, I'd be surprised if this hasn't already been addressed in the wealth of new functions Nib's bolted on recently. Scott. Scott.

Remort only continent perhaps?

Anyone else sick and tired of maxxed remorts moaning about having nothing to do?

Scott.

PS - 1st post in the forum - woohoo! =)

I tried to say this ages ago, but the forum code ate it. Mierkwood… aren't we a little close to Middle-earth's "Mirkwood"? I tell ya, if you don't change the name, I'm going to have so much fun slaying morts who state the obvious... Scott.

I'd like to point out that Durron reported the bug, not SCo. SCo did test whether or not STR etc could be trained by unshifting and casting weaken (STR -5) on himself. The assumption I'm making is that the trainer code is checking current hp, rather than permanent hp when it's decided whether or not you can continue to train. Scott.

Hmmm… I wasn't aware that there was a chance factor in using a sextant. It's simple geometry. Surely that defeats the purpose of actually using a sextant. Might as well delete the item type completely, because certainly from my own point of view as a mort, I wouldn't bother using it if there was a chance it would give me completely useless coordinates. =p If you absolutely *HAVE* to add an unreliability factor to this, why not go with reality and base it on how much visibility/cloud cover there is. Scott.

Hi all,

When you stand in any wilds and use a sextant, over and over, the coordinates change - therefore sextants are useless! Odd one that.

Scott.

I assume this is a scripting device: (from achaeus.are) #MOBILE 265681 Name money mob~ ShortDesc a money mob~ LongDesc A mob for money stands here, waiting to die. ^M~ Description ~ Owner (no owner)~ ImpSig (none)~ CreatorSig (none)~ Skeywds none~ Race human~ Act 1 Act2 2 Level 1 Alignment 0 Hitroll 1 Hit 1 13 0 Mana 0 0 0 Damage 2 8 1 Movement 23 AttackType 0 Attacks 0 OffFlags 0 ImmFlags 0 ResFlags 0 VulnFlags 0 StartPos 8 DefaultPos 8 Sex 1 Wealth 4999999 Parts 2047 Size 2 Material unknown~ #-MOBILE

Didn't know where else to put this, so I'll just put it in here.

I modified the seedy shopkeep in achaeus. Check this out:

[MEdit][265646] 265646>
show
Name: [seedy shopkeep]
Area: [ 58] Achaeus
[b]Sig: [(none)][/b] Creator: [(none)]
Act: [npc sentinel protected]
Act2: [noquest]
Vnum: [265646] Sex: [male ] Race: [goblin]
Level: [ 120] Align: [ 0] Owner: [(no owner)]
Hitroll: [ 0] DamType: [none]
Movement: [ 1570] Number of attacks: [0]
Hit dice: [120d195+9000] Damage dice: [14d35 + 120] Mana dice: [ 0d0 + 0]
Affected by: [detect_invis detect_hidden infrared]
Affected by2: [none]
Armor: [pierce: 0 bash: 0 slash: 0 magic: 0]
Parts: [head arms legs heart brains guts hands feet fingers ear eye]
Imm: [summon charm]
Res: [disease]
Vuln: [magic]
Off: [none]
Size: [medium]
Material: [unknown]
Start pos: [standing]
Default pos: [standing]
[b]Wealth: [ 9000000][/b][color=#FF4000]!!!!!!!!!![/color]
Script Kwds: [none]
Short descr: a seedy shopkeep
Long descr:
A seedy shopkeep stands here, hoping to swindle another sucker.
Description:
This is a seedy goblin shopkeeper who is not the most intelligent being
in the vicinity, but knows how to swindle a fool. He wears some kind of
unidentifiable brown garb adorned with metal chains.
Shop data for [265646]:
Markup for purchaser: 110%
Markdown for seller: 75%
Hours: 0 to 23.
Number Trades Type
------ -----------
[ 0] weapon
[ 1] light
[ 2] armor
[ 3] artifact
[ 4] treasure
Number MobProg Vnum Trigger Phrase
------ ------------ ------- ------
[ 0] 265646 grall 100

[MEdit][265646] 265646>

I don't know what to make of this. I experimented with the wealth setting several times, and when i tried to set a wealth of more than 1000 i got "you can't do that - get an imp to sign the mob if you want to do this". So how the hell did someone set the mobs wealth to 9 mil???

Looks like people have been exploiting this wholesale, and it explains why some people spend all their time just whoring expensive equ to this shop. I've now set the wealth to a sensible value, so if anyone complains, you know why.

On the off-chance that one of you guys set this to 9 mil, I presume there's a good reason - and there's a good reason why the signing code failed. Might be worth checking the other shopkeeps in the game, cos this now explains why certain people suddenly have so much gold. Fuckin morts. This kind of thing really pisses me off.

Scott.

Hi all,

Various people have expressed an interest in UIDs, a feature I've had to implement on a limited-basis to accomodate the wilds v2 code. This thread is intended to explain what UIDs are, how they are implemented and how they should be employed in-game (assuming of course, that the code is adopted into the main build).

UIDs are "Unique IDentifiers", much like vnums, except that vnums refer to the originating index of an entity, not the entity itself. A hypothetical example to clarify this point is necessary:

Object: A Sword called "Bert".
Vnum : 100

This is the index or template, if you will, of the object - this is a reference to the "obj_index_data" structure stored in the area file. Then we "load obj 100", which creates an "instance" of that object, referring to the obj_data structure. These are also stored seperately in the area file should the object be loaded up by the area/room/mob, or stored in the players pfile should they be in possession of the object. However, there is currently no way to directly reference a particular instance of a loaded object, with the exception of the in-game method (1.sword, 2.sword etc). This is where UIDs come into their own.

The premise is that there is an absolute, unique identifier code for each and every instance of an entity in the game. For the wilds v2 code I've only implemented area/wilds/vlink UIDs for the moment, with mobs/objects to follow. When the game starts up it loads up a config file called gconfig.rc, containing a counter value for the next unused UID for each type of entity:

NextAreaUID 123
NextWildsUID 3
NextVLinkUID 27

UIDs are of course, unsigned longs, so you've got about 2.4 billion of them before it cycles around.

Areas:
It was necessary to implement UIDs for areas because area files themselves can be loaded in any order from the area.lst file. The game doesn't really care as long as the vnum range for the area isn't being used anywhere else. The problem is that the wilds does care, and I didn't want to go faffing about with hard-coded area names all over the code. An area with a UID can be loaded in any order you like and the code will still find that code. You can have two copies of the same area, and still be able to access the one you intended as long as they both have different UIDs.

Wilds:
In order to implement multiple wilds sectors within a single area (so making wilds files children to a parent area), UIDs were required in order to directly reference a particular wilds sector. This is handy in itself - a new command "goxy" that allows an imm to jump to a particular map reference in a wilds, also takes a third argument for the wilds UID file, i.e "goxy 433 448 1" puts you at the crossroads outside the eastern Plith entrance, regardless of where you were in the game at the time. I can add hundreds of other wilds files, even copies of the sent wilderness and still be able to jump directly to the same place in the same wilds. Correspondingly, if a particular instance of wilds is missing, you can't jump to another one and start editing by mistake - the code will warn you that the UID isn't available.

VLinks:
VLinks are an odd one. When i set out with the wilds code, vlinks were just links between wilds and areas. Due to one thing or another, and a lot of input from people like Nib, they're gradually becoming an all-purpose dynamic link, modifiable by scripts (eventually). UIDs allow things like a mob in the wilds being able to link or unlink a VLink from script - unlink THAT link in THAT wilds sector, at THIS location.

Mobs/objs:
Mobs and objects are probably where UIDs will come into their own. mobs and objects start out as reloadable indexes, or templates. The game then loads up each instance of them with stats within a defined range of values. UIDs allow you to load up a particular mob/object and be able to reference THAT particular one directly. This lends itself to things like mob memory, directly accessing the values/tokens of specific mobs/objects, accessing or modifying the affects on something.

That's it. Any questions, suggestions, show-stoppers, fire em into this thread.

Cheers,

Scott.

Hi,

Opening a thread for discussion of the idea about having variable entity sizes. Right now, and excuse the Dawkinsism, all our characters, mobs, objects and locations are made from the perspective of "middle-world". For the uninitiated, "middle-world" (no relation to "Middle-earth") is the sense of perspective that we as humans are used to dealing with, neither very big or very small.

The idea I propose is that either through character "skill", magical effect or some other method, entities like characters could be resized - for example, a character morphing into an ant, perhaps for the purpose of sneaking under a door, or through a hole in a wall. This could be expanded through the use of either wilds or hidden areas specifically designed to cater for the change in perspective. At this point I'm not proposing that this would become in any way a major part of the game, rather more of an interesting diversion.

I haven't had a lot of time to think about it yet, but here's an off-the-top-of-my-head example of the kind of thing I envisioned for this:

Character happens upon a solid, locked door. There is absolutely no way past, and the key has been broken off in the lock and rusted over time. Magical unlock won't work, but the char notices a tiny hole in the base of the door. The char uses a racial or magical skill to morph into an ant, and enters the hole. They find themselves inside a little mini-area with multiple paths, deathtraps and or puzzles etc that have to be negotiated or solved. Eventually they work their way to the lock mechanism and are able to loosen the bolt. Normal size characters outside the door would simply hear a *click* from the lock to notify them that the lock had been opened.

Other examples might be, being able to climb into the mechanisms of things like a bridge lowering mechanism, portcullis mechanism. I'm half wondering about whether we could use Nib's crossbow stuff to fire a minaturised character over a castle wall attached to a projectile.

So far, I've only provided examples of the small end of the scale of resizing. Being able to morph into very large entities might also be interesting. For the moment I want to leave combat to one side and concentrate on the exploration side of play. (Combat poses serious issues with the fite code for very large or very small characters). Say for example a formation reaches a large chamber with an impassible ravine - water at the bottom, so flying spells are out. A fallen pillar to one side looks like it could be used as a bridge, but it's made of marble and so there's little or no chance of being able to move it - except one of the party is able to morph into a cave troll with STR 80. They do so, and are able to lift and place the pillar across the ravine.

I just think it's an interesting tangent to talk about, should anyone be interested.

Cheers,

Scott.

Excuse my continued and well-lamented frustration at the limitations of rom. I didn't mean to suggest that that was what you were advocating. It's just you pretty much laid the smack down on an idea before we had time to discuss it further. Of course you're entitled to your opinion. I'll take the resize aspect of the transmogrify idea to another thread. Scott.

As with all my posts, I didn't post my ideas to in any way restrict the scope of discussion around yours, Pol. I agree that transmogrify would be an interesting path to explore. But you have to agree that there is very little in the way of variation of play in rom. We're all the same size(ish), shape(ish), and have more or less the same set of abilities and features, give or take the occasional tangential racial features. With the seemingly inevitable bleed of skills/spells into multiple classes, I'm just getting a little tired of the same old bipeds around 6 ft tall(ish), going at it toe-to-toe with the same old middle-earth inspired weaps, with the same old rpg-inspired spells. Forgive me for looking to introduce the occasional interesting diversion, like maybe discovering a small hole in a room you've been in a thousand times, "this hole looks about big enough for an ant.", transmogrifying into an ant and finding a whole new area to explore. It might not appeal to the die-hard PKers, but some people are looking for something else to do other than hack/slash/level/get beat down constantly by people who have been here long enough to establish an unassailable advantage (see PC's with 50+ str, or 5000+ hp for example). Boring boring boring. Scott.

> Fatal error: Call to a member function bbcode_second_pass() on a non-object in /home/.doggs/sentience_imm/immsite/viewtopic.php on line 1241 Trying to post a reply. Scott.

Red mentioned this in passing - it would appear that if you use word of recall or some other transport spell, the relic will stay where it was until you actually move, at which point the relic suddenly ends up back at your location. I don't know how this happens because I haven't checked the code, but I'd surmise that there's a pointer to the relic object in the char_data structure, and when the char does the spell, the code doesn't explicitly take care of the pulled cart - but then the char moves and the movement code takes care of it by referring to the cart pointer. I would suggest it would be more elegant either to deal with the cart explicitly in the transport spell code, or simply make it so that you can't use transport spells while pulling a cart. Personally I'd prefer the former, but that's me. If you do go the route of allowing transport spells while pulling a cart, then perhaps you will also consider allowing slayers/chlings to "fade" while pulling. This would give the "fade" skill a practical use. At this point, I'd like to point out another bug, but I'd also like to relabel it as an opportunity. If I'm pulling a cart through the wilds myself, I get lagged by the weight of the cart. Annoying, but fair enough. However, if I follow someone else while pulling the cart, and they drive (so-to-speak), then the lag disappears and we move together at full speed. I didn't know if this was a bug or a deliberate feature, but how about we make it so that the more people you have in your form, the faster you can move with a cart? Divide the load between us. That's prolly the simplest way to do it. If you wanted to get clever, you could have one person pulling and the rest have to "push". Personally I like the form idea better for simplicity. Just a suggestion. Scott.