On Game vs Simulation...

I read these boards every day. Some suggestions I like, some I don't, but it is slightly hostile to new players who make suggestions, and a us vs them mentality. I've seen lots of good suggestions go down to a hail of "its-fine-the-way-it-is", "devs have no time\they do this on your their own time, be grateful for what you get", "We shouldn't listen to the vocal minority" and so on.

And yet I doubt there was anyone who didn't play multiplayer, new or old player who would want that Pause feature,

I wonder if the structure and codebase is slowing things down a lot. Right now there's something like 30 simulation executables, each with copies of the core code, the layout and interlocking data, and the custom code specific to that sim.
[...]
Now any change to the core code would potentially need to be done to 30 different versions of the code, with a lot more variation in functionality. Any non-trivial change or bug fix would need to be potentially be implemented in a different way on each sim,

I believe every build every dev makes has to be compiled\vetted by Geoff,

factor in testing (How much is automated?)

Have you ever thought of moving all the code into a single SimSig.exe, and having a seperate binary .layout file that used some private SimSig API or something?

Any changes and fixes would only need to be implemented and tested once, and every sim gets the new feature or fix. The exe could be continually updated a lot more frequently, and if a core bug is found, fixed and tested in days or hours even.

The .layout file would only have data, and if the data is isolated from the code, much easier to test and update.

Central Scotland\NE Scotland and Worksop have 3 different versions of mechanical interlocking, and since the core code was never intended to support that, its sort of hacked in there in the custom sim code.
[...]
If all that mechanical code was moved into the core code, all the sim dev needs to worry about is specifying that a block instrument exists what type it is, and who it talks to.

The layout data is fairly static,

If a sim developer only has to worry about the layout and not the code, I bet it would take a lot less time to develop, and you could have more developers who wouldn't need to know about the intricacies of the core code.

SimSig is a rather difficult game to "get"... Not knowing anything about what an IECC looks like, it looks like a game with 20 year old graphics, with not a lot happening, and as is modelled after actual IECC equipment etc, not very forgiving on the new user.

I have 2 monitors, and I like the expanded view. I can't live without sticky notes now either.

It's a lot easier to keep the relevant development tools under control than to chase down the creators of unauthorized sims.

I don't believe that Geoff is intending to allow just anyone to write simulations. Apart from anything else, how could we continue to ensure the quality of what's produced?

Frankly, I think the user base, not the devs, should be the judge of this.

Actually I think it pre-dates multiplayer; it's been around a long time.

Um, do you know anything about commercial software development? Things just don't work like that.

There is one master copy of the core code source. This gets bugs fixed and features added and, every now and again, is used to build what is effectively a library that gets sent to the sim developers. Fixes are not put into older versions - if a developer wants a bug fix, they have to move to the latest version. More on this below.

Quote:

I believe every build every dev makes has to be compiled\vetted by Geoff,

You believe wrong. Releases get vetted (and not even releases to testers, just public ones).

Testing is done by the sim developer and those who he's asked to assist him. Geoff doesn't do it. (Very little is automated for various reasons.)

{mode=sarcasm} Would you like some egg-sucking lessons? {mode=normal}

Let me give you one example of why this isn't anywhere near as easy as you make it sound.

I'm currently working on a new feature for the core code that affects the way in which timetables work. Based on developer comments so far, I expect it to be received rapturously by most players. Now about 98% of this feature will work automatically as soon as you rebuild a sim with the new core code, but there will be a few places where the layout information needs to be changed and, for a range of reasons, it isn't possible to automate that last 2%. Furthermore, if it isn't done then the feature will look really horrible and broken. So I have two choices. I can disable the feature by default and require sim developers to put a significant effort in to make it available, or I enable it by default but say that all sims (yes, even Drain) require changes - albeit minor ones - to use versions of the core code later than N.NNN. I've chosen the latter.

Quote:

The .layout file would only have data, and if the data is isolated from the code, much easier to test and update.

You don't know anything about this stuff, do you?

Quote:

The layout data is fairly static,

Sounds of hollow laughter.

The sim developers don't know about the intricacies of the core code.

but what matters most is enjoyment and playability

Kage, interesting that your early experiences with SimSig parallel mine. Also similar backgrounds, non-UK, enjoy anything to do with trains, unfamiliar with the idiosyncrasies (the only word for it) of British railway signalling.

Since you read this forum regularly, you probably came across a recent thread of mine that basically asked the same questions and got similar answers. Putting the two threads together, it's plain that SimSig is no SourceForge; we should feel privileged to be invited to participate at no up-front cost in an application written by people professionally trained in this field, to appeal mainly to like-minded individuals; preaching to the converted, as it were. This explains why authenticity takes precedence over usability when there is a conflict, and also why the lack of adequate documentation frequently goes unnoticed. We should be grateful to all the folk here who understand our plight and are willing to share their years of experience with us.

Having said that, I have to concur with you on a lot of what you said.
SimSig is a rather difficult game to "get"... Not knowing anything about what an IECC looks like, it looks like a game with 20 year old graphics, with not a lot happening, and as is modelled after actual IECC equipment etc, not very forgiving on the new user.
I agree the graphics reminds me of those on the first computer I ever bought (no, I won't say how long ago that was). Practical but incredibly primitive, particularly the unrelenting upper case. Took a lot of convincing that real IECC panels are like this. But for how long? I wonder if SimSig would ever change if China or India suddenly flooded the market with cheap sim software based on moving-block technology, with all the nice graphic conveniences we have come to expect in other applications?

Kage, interesting that your early experiences with SimSig parallel mine. Also similar backgrounds, non-UK, enjoy anything to do with trains, unfamiliar with the idiosyncrasies (the only word for it) of British railway signalling.

Since you read this forum regularly, you probably came across a recent thread of mine that basically asked the same questions and got similar answers. Putting the two threads together, it's plain that SimSig is no SourceForge; we should feel privileged to be invited to participate at no up-front cost in an application written by people professionally trained in this field, to appeal mainly to like-minded individuals; preaching to the converted, as it were. This explains why authenticity takes precedence over usability when there is a conflict, and also why the lack of adequate documentation frequently goes unnoticed. We should be grateful to all the folk here who understand our plight and are willing to share their years of experience with us.

Quote:

I agree the graphics reminds me of those on the first computer I ever bought (no, I won't say how long ago that was). Practical but incredibly primitive, particularly the unrelenting upper case. Took a lot of convincing that real IECC panels are like this.

Gameplay always trumps graphics for me :D
The first IECC was in 1989, it's early 80's display technology. Also makes it easier to simulate as well..
That's why I like SimSig, realism miles above anything else out there...
My favorite though are the big NX panels, lots of lights and colours, very tactile...

Quote:

Sticky notes are a great innovation - I wonder if IECC panels have them?

Nope, but NX panels are covered in them, as well as magnets, posters, notices etc.

I don't think SimSig is an IECC simulator anymore, its trying to be a bit more of a generic panel simulation,
what with the transition to scrolly etc.

Quote:

As you say, the older we get, the worse short-term memory becomes.

Mine is already bad, I get a call that a train is entering somewhere, by the the time I close the window,
I've forgotten where it is, and what it's called. Then I realize a class 1 is stopped at a junction somewhere...


Quote:

2) The developers insist on "quality sims".

I insist on them too...

Quote:

Quote:

I don't believe that Geoff is intending to allow just anyone to write simulations. Apart from anything else, how could we continue to ensure the quality of what's produced?

I think there's a financial and work related aspect here. One of the disclaimers was something along the lines of 'only for personal entertainment use only, not to be used for the training of signallers'

1) Legal issue, so no one can sue them if someone attempted to train professionally, and screwed up
2) TRE makes professional training simulations, with real controls, and multiple monitors, and assessor stuff, lots of custom stuff, very expensive, and would probably be rather annoyed at Geoff if any company could make there own for free...

I also think that he does need to maintain a certain level of quality, or it would reflect badly on TRESIM.

Quote:

Frankly, I think the user base, not the devs, should be the judge of this.

Careful there...


[quote]I personally think the rigid requirement for locale authenticity is a bit of an excuse, when one reads the fine print and sees what compromises have had to be made to convert it into a sim.
Some details have to be invented. Glaring errors generally get fixed. If I were creating an Australian sim based on four-aspect signalling, it wouldn't matter if track lengths, gradients, etc. weren't spot-on to begin with. Historical refinements could be discussed till the cows come home, but what matters most is enjoyment and playability.

I agree the graphics reminds me of those on the first computer I ever bought (no, I won't say how long ago that was). Practical but incredibly primitive, particularly the unrelenting upper case. Took a lot of convincing that real IECC panels are like this. But for how long? I wonder if SimSig would ever change if China or India suddenly flooded the market with cheap sim software based on moving-block technology, with all the nice graphic conveniences we have come to expect in other applications.

Sticky notes are a great innovation - I wonder if IECC panels have them?

The developers insist on "quality sims".

Frankly, I think the user base, not the devs, should be the judge of this.

I personally think the rigid requirement for locale authenticity is a bit of an excuse, when one reads the fine print and sees what compromises have had to be made to convert it into a sim.

Some details have to be invented. Glaring errors generally get fixed. If I were creating an Australian sim based on four-aspect signalling, it wouldn't matter if track lengths, gradients, etc. weren't spot-on to begin with. Historical refinements could be discussed till the cows come home, but what matters most is enjoyment and playability.

maxand wrote:
I personally think the rigid requirement for locale authenticity is a bit of an excuse, when one reads the fine print and sees what compromises have had to be made to convert it into a sim.
Quote:

An excuse for what? Of course, some compromises have to be made since some things would be very difficult to code, but that shouldn't stop us aiming for realism.

Frankly, I think the user base, not the devs, should be the judge of this.

I agree the graphics reminds me of those on the first computer I ever bought. Practical but incredibly primitive, particularly the unrelenting upper case.

Quote:

SimSig is a rather difficult game to "get"... Not knowing anything about what an IECC looks like, it looks like a game with 20 year old graphics, with not a lot happening, and as is modelled after actual IECC equipment etc, not very forgiving on the new user.

I agree the graphics reminds me of those on the first computer I ever bought (no, I won't say how long ago that was). Practical but incredibly primitive, particularly the unrelenting upper case. Took a lot of convincing that real IECC panels are like this. But for how long? I wonder if SimSig would ever change if China or India suddenly flooded the market with cheap sim software based on moving-block technology, with all the nice graphic conveniences we have come to expect in other applications?

Kage, interesting that your early experiences with SimSig parallel mine. Also similar backgrounds, non-UK, enjoy anything to do with trains, unfamiliar with the idiosyncrasies (the only word for it) of British railway signalling.

Since you read this forum regularly, you probably came across a recent thread of mine that basically asked the same questions and got similar answers. Putting the two threads together, it's plain that SimSig is no SourceForge; we should feel privileged to be invited to participate at no up-front cost in an application written by people professionally trained in this field, to appeal mainly to like-minded individuals; preaching to the converted, as it were. This explains why authenticity takes precedence over usability when there is a conflict, and also why the lack of adequate documentation frequently goes unnoticed. We should be grateful to all the folk here who understand our plight and are willing to share their years of experience with us.

It's a lot easier to keep the relevant development tools under control than to chase down the creators of unauthorized sims.

2) The developers insist on "quality sims". Clive again:
Quote:

I don't believe that Geoff is intending to allow just anyone to write simulations. Apart from anything else, how could we continue to ensure the quality of what's produced?

Frankly, I think the user base, not the devs, should be the judge of this. I personally think the rigid requirement for locale authenticity is a bit of an excuse, when one reads the fine print and sees what compromises have had to be made to convert it into a sim. Some details have to be invented. Glaring errors generally get fixed. If I were creating an Australian sim based on four-aspect signalling, it wouldn't matter if track lengths, gradients, etc. weren't spot-on to begin with. Historical refinements could be discussed till the cows come home, but what matters most is enjoyment and playability.

As far as I know, even if the core code is a library, there are still ~30 different projects, each with there own custom code.

If SimSig was built for a commercial client, and they asked for a change like the one you mention to Timetable, how long would it take to make the change in the core code, apply it to every sim, and completely test and fix all of them?

If the core code is something binary linked library, Any change to the library could possibly break the custom code.

and wondered why there wasn't any sort of automated unit testing suite

I'm not sure exactly what the layout data contains, I figure it has all the visual elements, and the model data and logic for everything. As far as I know the only thing the data has to do with the core code timetable is that it contains the list of timing points and other timetable locations. The layout should not be dependent on an specific implementation of the Timetable class. If it was only dependent on a ITimetable interface, you could swap in new implementations as needed.

If your logic data was only dependent on an ILayout, you could set up a really good automated test, where it used a mock non visual ILayout to automate sending UI events.

it seems that

Any change to the core code can potentially break either the custom code, or the layout data
Any change to the custom code can potentially break the layout data.
Any change to the layout data can potentially break the custom code.

For instance, say the dev of NEScot wanted to use Worksop's mechanical box code.
Since it's not a core function, it would require a lot of work to integrate it, and require the layout data to use the different controls and logic, and a lengthy period of manual testing.

Quote:

Quote:

The layout data is fairly static,

Sounds of hollow laughter.

Sorry, did I miss something?
The layout data only needs to be updated as far as I can see, to fix
things like typos, and corrections to the model data, ie signal logic.

When a paged sim is converted is converted to a scrolly sim for example,
The visual data representing the controls should for the most part stay the same, except for the circuits that used to span across pages. The underlying model representing all the signal and track logic for the most part should be the same.

Quote:

The sim developers don't know about the intricacies of the core code.

I stand corrected. Who writes the custom sim code then?

It is easier to write custom code to handle the local peculiarities of each sim than to write a one-size-fits-all package for which we can write layout scripts, as you and I have both suggested. Although programming is hardly rocket science, each sim as you've noticed contains a great deal of intricate, handcrafted code which would take a bit longer to learn to debug - unless you are prepared to spend time getting up to speed.

Quote:

SimSig is a rather difficult game to "get"... Not knowing anything about what an IECC looks like, it looks like a game with 20 year old graphics, with not a lot happening, and as is modelled after actual IECC equipment etc, not very forgiving on the new user.

I agree the graphics reminds me of those on the first computer I ever bought (no, I won't say how long ago that was). Practical but incredibly primitive, particularly the unrelenting upper case. Took a lot of convincing that real IECC panels are like this. But for how long? I wonder if SimSig would ever change if China or India suddenly flooded the market with cheap sim software based on moving-block technology, with all the nice graphic conveniences we have come to expect in other applications?

Quote:

It's a lot easier to keep the relevant development tools under control than to chase down the creators of unauthorized sims.

2) The developers insist on "quality sims". Clive again:
Quote:

I don't believe that Geoff is intending to allow just anyone to write simulations. Apart from anything else, how could we continue to ensure the quality of what's produced?

Frankly, I think the user base, not the devs, should be the judge of this. I personally think the rigid requirement for locale authenticity is a bit of an excuse, when one reads the fine print and sees what compromises have had to be made to convert it into a sim. Some details have to be invented. Glaring errors generally get fixed. If I were creating an Australian sim based on four-aspect signalling, it wouldn't matter if track lengths, gradients, etc. weren't spot-on to begin with. Historical refinements could be discussed till the cows come home, but what matters most is enjoyment and playability.

Gameplay always trumps graphics for me

Frankly, I think the user base, not the devs, should be the judge of this.

It seems Max that you are suggesting that a developer should let ordinary members (you and I) decide whether a sim is realistic

It'd be a damn site easier if we weren't so rigid as we could build any old things really quickly.

signal 76 in the Bristol Modern Era sim desperately needs to be capable of automation, but isn't. If I could change it, I would. It's only a minor detail

User generated content is inevitably going to produce some buggy, low-quality products - take a look at any "moddable" game. The devs don't want to spend time running around answering "how do I code a signal?" and "so-and-so's sim broke my computer!". It actually seems a bit insulting for you to say "they're just making excuses when they say they're trying to be accurate".