Removing numbers from a text file

Page: 1 2
May 5 2012, 8:52 am (Edited on May 5 2012, 9:10 am)
Play to the strengths of the language. Creating all items as individual text strings is a little silly when the language offers you ... well. Objects.

You still haven't explained why you can't just store
item
    var
        name
        quantity
        description


and then, when a player has an item, do

WhereeverItemsGo << "[quantity] of [name], [description]."

- the name can be whatever you like. Heck, if you wanted you could give the player a generic "obj/item/thing" and then set the name using Input()to "Potions of Pit-Leaping" or something, since you said you plan to have so many items you think coding them all in individually is a waste of your time.

EDIT:
I see you specifically want an environment to work with a DnD-style game? Are you aware of BYOND's existing Tabletop Gaming suite? Or a newer but less general-purpose suite?
May 5 2012, 10:27 am (Edited by moderator on May 5 2012, 10:28 am)
well, for all that trouble I found my answer, thank you Keeth for answering my question even if you don't necessarily agree with my methods of implementation. I have tested the following and it will do the job:
    Use_an_item(var/i in usr.Items)
        set category="Player Verbs"
        usr.Items-=i
        var/num=text2num(i)
        var/found=findtext(i, " ")
        var/restofit=copytext(i, found)
        num--
        var/newi="[num][restofit]"
        usr.Items+=newi


Mod note: Please place code between the <dm> tags so that it properly renders, thanks.
May 5 2012, 10:29 am
In response to Deathguard
No, I was not aware of this at all, and it may definitely be something to look into but I have put a Lot of typing into this so far so I might just see it to fruition, otherwise my fingers will never let me live it down! D:
May 5 2012, 11:06 am
Before I give up on you, I'll just let you know that you are essentially using strings to pretend to be objects here. You are going the long route and creating a string that can be parsed to retreive object data. Except with this, you have to re-read the string every time you want to access your object's information.

For someone claiming to come from C++, I really don't understand why you would think this is the route to go with.
May 5 2012, 11:08 am
I'm saying for my purposes and the way I have it set up, it would save me having to go through and recode half the entire game.
May 5 2012, 11:15 am
Recoding half the game now may save you a great deal of time and pain later. Fundamentally bad design taking time to replace isn't an excuse to keep developing that bad design 'because it's faster.'

Keeth has a deal of experience and ability with the language, and I agree with him here.

We 'get it.' The way you've done it now looks like it works for you. You've written a lot of code that way. It doesn't make it smart to keep doing it that way.

If you want to make a game that works, with a code base that actually makes sense and isn't eye-searingly unreadable and unreliable, go back. Start over. Use objects. It's an object-oriented language for a reason. The way you have it set up might work now, but it's just mind-boggling why you'd do it that way when a much better, easier and simpler way exists.

To draw a similarity;
It's like the difference between having multiple procedures with 10 IF - THEN nests per procedure, and writing one datum now and reusing it later.
Page: 1 2