Can I do this?

[nullquery]

Hi,

Wondering what changes will be allowed on /tg/.

My latest development is still the html_interface module. I'm hoping to continue work on this, but first I'd like to know if there are oppositions to any of the following other changes overhauls I have in mind:

• Either condensing type paths and/or run-time definition of items (specifically clothes and blunt instruments). I'd like to do this in order to reduce the amount of time it takes to compile the game.
• A single database engine for persistent data storage. Either via SQLite and/or MySQL. To avoid the creation of dozens of savefiles and allow external tools to query game data.
• A single method of configuration. To avoid all the various ways configuration files are being read.
• Reworking the administrator system. Verbs are helpful additions, but introduces a lot of clutter. Reduce verbs where acceptable, merge everything into browser windows and provide a dashboard/an overview of the game.
• In general: Making things modular if I don't need them on my own server.
• In general: Making things configurable if need be.
• In general: Making things extendable so I don't have to touch a single line of /tg/ code for custom modifications.

Any concerns about any of this?

[oranges]

If you can do these things in a way that improves the code quality and also easy enough for others to understand and use, then it should be fine.

That's a fair chunk of work though, also bear in mind we have had performance trouble with the mysql DB (slow reads and writes), I can't remember exact details, MrStonedOne can probably talk more on this specifically.

[oranges]

Also a big +1 to the single configuration method, also a more generic framework for getting/setting/adding configs, as it's a bit shit to do so right now.

[Remie Richards]

Either condensing type paths .... I'd like to do this in order to reduce the amount of time it takes to compile the game.

Do you mean doing this:

Code: Select all

/mob/living/carbon/human

-->

Code: Select all

/human
    parent_type = /carbon

/carbon
    parent_type = /living

or

Code: Select all

mob
    living
        carbon
            human

As both reduce the compile time of the game, however, NEITHER is happening. the code readability is worth FAR MORE than the compile time.

[MisterPerson]

I assumed it was more like obj/item/weapon/foo -> obj/item/foo

[nullquery]

I meant neither, sorry.

I'm referring to removing useless declarations altogether (map objects ftw) and/or moving some definitions to runtime (with a shared type path).

One last thing I'd like to look into is removing the map from the compile process, instead loading it at runtime. I'm not sure how feasible this would be though I know Lummox was looking into dynamically loading map files at runtime, so it may be worth waiting for.


I'm glad to hear all of this and I hope I can begin contributing proper "soon".

Thanks all.

[Scott]

As remie said, code readability is more important, so don't touch them type paths.

[Ricotez]

Why would you want to move things away from compile time and add them to run time? Compile time only has to be carried out once per version of the code, but run time must be performed every time the server restarts the round. Which it does every half hour or so.

I know that the code is a bit of a mess sometimes, but overall it's actually pretty readable. You are not working with some kind of super efficient software that only a few coders will see, this is an open source project that dozens of people have worked on in the past, and dozens more will in the future.

[nullquery]

Why would you want to move things away from compile time and add them to run time?

Because then you can decide if you need to load it, or if it can happen later.

Also IIRC if you run a server it still has to load all the type paths. Reducing them would then be a positive change at both compile and runtime.

[MisterPerson]

There's a lot of redundant type paths that could be removed, but loading the map at runtime would be hella slow.

[nullquery]

but loading the map at runtime would be hella slow.

I'm thinking that this might work if the map is loaded during the time players are setting up their character. Or at least parts of the map.

And there's a bunch of parts that aren't used. Don't need to load the Central Command part of the map when the game has just started, so makes sense to defer that.

[nullquery]

Also to alleviate any possible concerns: if I'm going to work on this I'm definitely making it configurable so people that don't want it don't have to use it. But I would still like it to be accepted to /tg/, which is kind of my point with this thread. To push changes that /tg/ may not necessarily use, but which would be a huge help for anyone that needs it.

[Jordie0608]

I'm thinking that this might work if the map is loaded during the time players are setting up their character. Or at least parts of the map.

Few people actually spend much time setting up characters as most already have their save files; also I suspect with how our current handling of new players is to load them onto the map as a mob and give them verbs, the start panel etc. that loading at runtime would make that much longer.

[MisterPerson]

It's worth a proof of concept, if nothing else. The going theory is that goonstation loads some of the solarium dynamically at roundstart.

[Remie Richards]

Nullquery showed off dynamic map loading and saving in chunks for their game in the IRC the other day.
it wasn't perfect, but it was good.

there was a lot of neat features (Computers with consoles, Networking, Wiring, programmable bots) and when the server would go down it'd reboot in about a second.
so yeah, they should be given a chance.

[MrStonedOne]

Either condensing type paths and/or run-time definition of items (specifically clothes and blunt instruments). I'd like to do this in order to reduce the amount of time it takes to compile the game.

You have gonna have to give examples, many examples, as to what you mean.

A single database engine for persistent data storage. Either via SQLite and/or MySQL. To avoid the creation of dozens of savefiles and allow external tools to query game data.

I had this idea, if you did it right, and ensured you only used queries that both supported, it would be easy to do sqlite with mysql as an option (we need it since sybil and basil have no way of talking to eachother)
The biggest question, is how you handle importing the old data when we have multiple servers. players only get 3 char slots, but basil and sybil could each have 3 different characters.
Same for notes.

A single method of configuration. To avoid all the various ways configuration files are being read.

Yes please!

Reworking the administrator system. Verbs are helpful additions, but introduces a lot of clutter. Reduce verbs where acceptable, merge everything into browser windows and provide a dashboard/an overview of the game.

Before things can be moved to browser windows, the mess that is admin/topic() needs to be handled, badly.

In general: Making things modular if I don't need them on my own server.

The only push back you might get is if that modularity comes with a cost of complexity

In general: Making things configurable if need be.

Yes and no, There is a sizeable amount of people who think the config options have gotten out of control. I'm thinking maybe remove some of the config options that really don't need to exist, like health and crit numbers, (the game isn't balanced to anything else) and the like, that are almost never changed.

In general: Making things extendable so I don't have to touch a single line of /tg/ code for custom modifications.

Good luck. =P

That's a fair chunk of work though, also bear in mind we have had performance trouble with the mysql DB (slow reads and writes), I can't remember exact details, MrStonedOne can probably talk more on this specifically.

This issue was fixed (for us at least). Mysql has a fuck ton of caching now, and its not even using it all. Its also on the same box as the other servers in its own vm.

One thing is that indexes need to be checked, I had to create some for our database, and I don't think they made it into the schema.