29 Jan, 2015, wifidi wrote in the 1st comment:
Votes: 0
Sorry for posting again on this topic when I said I wouldn't, yet check this out:
302hp 232m 490mv> oe
These extra flags are on these many items…
glow: 0
hum: 0
dark: 0
lock: 0
evil: 0
invis: 0
magic: 11
nodrop: 0
bless: 2
anti-good: 0
anti-evil: 0
anti-neutral: 0
noremove: 0
inventory: 0

<302hp 232m 490mv> ot
These types have these many items…
light: 5
scroll: 2
wand: 0
staff: 0
weapon: 11
treasure: 1
armor: 48
potion: 1
furniture: 3
trash: 2
container: 5
drink_con: 9
key: 7
food: 6
money: 4
boat: 2
NPC corpse: 1
PC corpse: 1
fountain: 2
pill: 0
darkness: 1

<302hp 232m 490mv> owf
These wear locations have these many items…
finger: 3
neck: 2
body: 7
head: 5
legs: 5
feet: 5
hands: 5
arms: 5
shield: 3
about: 2
waist: 2
wrist: 4
wield: 11
hold: 3

<302hp 232m 490mv>
otfind in commands.cpp:
if (arg.empty()) {
int type[] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
for (int vn = 0; nMatch < ObjectPrototype::top_obj; vn++) {
if ((pObjIndex = get_obj_index (vn)) != NULL) {
nMatch++;
type[pObjIndex->item_type]++;
}
}
snprintf (buf, sizeof buf, "These types have these many items…\nlight: %d\nscroll: %d\nwand: %d\nstaff: %d\nweapon: %d\ntreasure: %d\narmor: %d\npotion: %d\nfurniture: %d\ntrash: %d\ncontainer: %d\ndrink_con: %d\nkey: %d\nfood: %d\nmoney: %d\nboat: %d\nNPC corpse: %d\nPC corpse: %d\nfountain: %d\npill: %d\ndarkness: %d\r\n", type[1],type[2],type[3],type[4],type[5],type[8],type[9],type[10],type[12],type[13],type[15],type[17],type[18],type[19],type[20],type[22],type[23],type[24],type[25],type[26],type[27]);
send_to_char(buf);
return;
}

These specifics can also be extended to owhere. Ofind shows items on file, owhere shows items in the game. I know its more intuitive to write SQL for these, the idea being to put it all into a database once then simply issue neat SQL per command. Code that duplicates the functionality of a database, particularly for a game (Murk++) that comes with a database, could seem absurd. I haven't loaded the world into the database because it already exists and works fine (see memory, o/r/mfind, etc.)

I'm in a database class in college, so by the end of the semester I'll have a better idea of whether to load it in. It seems like I'm heading "off the cliff" writing many similar sections of code. Maybe there really is only so much to write, in which case I could be closer to done now. The question remains what qualifies for release. Sure seems like SELECT Name, Damage, (etc.) FROM Items WHERE ItemType LIKE 'weapon', or some such statements, are way smarter.
29 Jan, 2015, plamzi wrote in the 2nd comment:
Votes: 0
wifidi said:
The question remains what qualifies for release.


I'm not sure what your question is exactly.

If you're asking about a release for your own game, there's really no better judge than you. In the hobbyist realm, ugly code that works fine is better than pretty code that is never quite perfect enough to see the light of day.

If you're asking about a codebase update, I would say exactly the opposite. I did some quick reading and it seems the last version of Murk++ comes with sqlite tables for world entities but they are not actually in use. The obvious next step is for someone to import a world into those tables and start tapping into the powers of SQL queries. A decade too late is better than never.
30 Jan, 2015, wifidi wrote in the 3rd comment:
Votes: 0
plasmi said:
I did some quick reading and it seems the last version of Murk++ comes with sqlite tables for world entities but they are not actually in use. The obvious next step is for someone to import a world into those tables and start tapping into the powers of SQL queries.


My question is definitely about writing code to be included in a codebase release, which you've answered. Loadhelps.exe loads some files into the database and the source is included. Programmers like me who have to copy the author can easily add to Loadhelps and even rename it loaddata or loadDb. I guess I have to check my own chin even when simply implementing the common sense queries because I still dream about playing a classic MUD as a warrior and probably wouldn't want to multitask and be mediocre at both. The nice thing about straitforward developments is there's no way to "mess them up" e.g. everyone knows what item queries should show. Knocking out a lot of that work would give others the opportunity to work on something else. I tried programming NPC logins and ran into how much more has to be known to code it well. Another thing that'd be nice is to think of a revolutionary way to online create. The best I can think of is using voice recognition software.

Thanks for writing. I have to say I'm more a fan than a contributor. It is really fun coding and seeing it work.
30 Jan, 2015, plamzi wrote in the 4th comment:
Votes: 0
wifidi said:
Loadhelps.exe loads some files into the database and the source is included. Programmers like me who have to copy the author can easily add to Loadhelps and even rename it loaddata or loadDb.


Loading files into the database is only the necessary first step. It's a very small step even when compared to the very next step: converting the codebase to load from the database rather than the files. Which in turn is a small step compared to the work needed to start saving to the database. Which is all a drop in the sea compared to retooling the rest of the code to take advantage of the db. Don't mean to scare you, but it is what it is.
31 Jan, 2015, Rarva.Riendf wrote in the 5th comment:
Votes: 0
Nah you scare him right. Loading/saving to a database instead from file is quite easy. After all, database or not, data should go through single methods of save/load. Not that hard/slow to rewire.
The tools can be written as you need them, so again, not really a hard work in itself.
Storing data in flat txt files or a database is strictly the same if you did the first step right: abstracting the frontend of the storing api. savechar loadchar or anyother method that save data.
I would say THAT part is the hardest one, depending on the initial codebase.
0.0/5